[scribus] [Scribus] newline issue in pdf fields

Mon May 2 16:18:38 UTC 2011

On Sunday 01 May 2011 16:09:14 Hans-Peter Jansen wrote:
> Hi Greg, hi a.l.e,
> 
> On Sunday 01 May 2011, 14:11:45 Gregory Pittman wrote:
> > On 05/01/2011 06:39 AM, Hans-Peter Jansen wrote:
> > > Hi a.l.e,
> > > 
> > > first of all, thanks for your attention.
> > > 
> > > On Sunday 01 May 2011, 11:06:09 a.l.e wrote:
> > >> hi pete,
> > >> 
> > >>> Much more
> > >>> importantly, the line break handling changed (again):
> > >>> now all test fields add a newline in front of each line in 
the
> > >>> resulting pdf (in the drop down _and_ the text fields), but 
OTOH,
> > >>> the text including newlines is displayed just fine in 
scribus
> > >>> itself.
> > >>> 
> > >>> A minor issue is the vertical text alignment in the single 
line
> > >>> text fields (now top, centered before).
> > >>> 
> > >>> It would be very kind, if somebody could have a look 
into these
> > >>> issues, especially into the newline handling.
> > >> 
> > >> i've tried to replicate but since i don't have your font
> > >> installed, i don't see exactly what you see on your 
monitor...
> > >> 
> > >> can you exactly describe one of the problems? (one single 
text
> > >> which is wrong how can i see that it is wrong...)
> > > 
> > > If you compare the two pdfs, you will notice, that some 
multiline
> > > fields display a plus in the down right corner for the 1.4 
version,
> > > meaning the field carries some cropped lines, while the 
correct
> > > version displays all lines. Since this also happens for the 
drop
> > > down items, I believe, that scribus converts newlines from
> > > multiline text fields into a form that results in one 
_additional_
> > > linefeed per line, when displayed as PDF. Since scribus itself
> > > displays the text just fine (without additional linefeeds), this
> > > seems also unintentional.
> > > 
> > > Conclusion: the newline normalization for PDFs must be 
wrong (while
> > > 1.3.3.4 got it right).
> > 
> > Scribus never adds newlines. What there has been is a 
difference in
> > how the first line in a text frame displays, which results in its
> > baseline being farther from or nearer to the top of the frame. 
In
> > some cases, there may also be some changes in the font that 
do this.
> > In these situations it's hard to know which is "correct", but 
mainly
> > leads to some editing when a file might be loaded from an 
older
> > version. Minute changes in font size can help, or possibly 
shifting a
> > font a bi from the baseline.
> 
> Attached are screenshots from areas, where the different 
spacing is
> obvious. Forgive my ignorance, but looking at the menu 
appearance with
> each menu item taking twice the space now it is pretty intriguing
> (compare test-pdf-menu.png with test-pdf-menu-1.4.png).
> 
> The font in question is called Arial, and being one of the most 
often
> used non serif fonts out there shouldn't suffer from failures in 
this
> dimension (the document, while being creating under Linux must 
cope
> with the environment of windows users without visual 
distortions).
> 
> If you compare test-pdf.png and test-pdf-1.4.png, you see, that 
it's not
> only the first line, but any line, and results in vertical space of 5
> lines, that is occupied by ~ 2 lines now with huge gaps in 
between.
> 
> The exact history of the two sla files in this thread are:
> transport-order-test.{sla,pdf} were derived from a production 
document
> with 1.3.3.4 yesterday. Then I replaced scribus 1.3.3.4 with 1.4.0-
rc3,
> loaded the sla, saved it as transport-order-test-1.4.sla without
> further manipulations and generated transport-order-test-1.4.pdf 
from
> it. Hence just scribus was replaced in the equation, same 
system, same
> fonts, same everything else.
> 
> Interestingly, the difference in vertical line spacing only occurs 
for
> pdf _widgets_, either editable or the pull down menu. Simple 
text
> frames are rendered _identical_ (see "Versender"). Just load both 
PDFs
> into AR, select Receiver One from pull down and tab into the 
next
> widget in both documents. Now you can switch between the two 
documents
> and the differences are obvious. At least I hope so.
> 
> Thanks for your patience,
> Pete
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: test-pdf-1.4.png
> Type: image/png
> Size: 6930 bytes
> Desc: not available
> URL:
> 
<http://lists.scribus.net/pipermail/scribus/attachments/20110501/fa4c3f2e/
> attachment.png> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: test-pdf.png
> Type: image/png
> Size: 9713 bytes
> Desc: not available
> URL:
> 
<http://lists.scribus.net/pipermail/scribus/attachments/20110501/fa4c3f2e/
> attachment-0001.png> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: test-pdf-menu-1.4.png
> Type: image/png
> Size: 10925 bytes
> Desc: not available
> URL:
> 
<http://lists.scribus.net/pipermail/scribus/attachments/20110501/fa4c3f2e/
> attachment-0002.png> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: test-pdf-menu.png
> Type: image/png
> Size: 5270 bytes
> Desc: not available
> URL:
> 
<http://lists.scribus.net/pipermail/scribus/attachments/20110501/fa4c3f2e/
> attachment-0003.png> 
_______________________________________________
> scribus mailing list
> scribus at lists.scribus.net
> 
> Use http://lists.scribus.net/mailman/listinfo/scribus to 
unsubscribe or
> edit your options.
> 
> Scribus Forums are available at http://forums.scribus.net
> 
> Notice: Scribus mailing lists were migrated to a new host and 
now reside at
> lists.scribus.net, so a new list address scribus at lists.scribus.net 
has to
> be used.

Try another font from the ones that come with Scribus such as 
Nimbus Sans 
-- 
John Culleton
Create Book Covers with Scribus:
http://www.booklocker.com/books/4055.html