[Scribus] some layout stability concerns from freetype kerning bug

[avox]

Michael Koren wrote:
> 
> Hi,
> 
> Can upgrading external libraries affect the layout of text in existing
> documents? I wanted to voice some concerns regarding layout consistency in
> scribus documents prompted by my recent fun upgrading freetype. :)
> 
> For example, I came across an old debian bug report
> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351251) saying that
> scribus and other programs no longer kerned truetype fonts with freetype
> 2.1.10. (It seems from the changelog and looking at the patch that
> truetype kerning briefly got disabled in freetype, though that was fixed
> in debian as of 2.1.10-2.) Since, as far as I can tell, scribus only
> stores the logical text and high-level formatting in a document, changes
> in the font metrics reported by freetype (even if they fix a prior bug)
> would change the rendering of text in an existing file.
> 
> This is a problem because it could break a carefully constructed layout. 
> 

Since this was a regression from freetype 2.1.9 to 2.1.10, users who
constructed such layout with
2.1.10 before Scribus had the workaround are out of luck. OTOH changes to
the layout due to kerning
changes should be rare and small.



> I don't know if other DTP programs have this issue as well, but in my
> opinion, part of the point of using a layout app is precisely creating and
> preserving document layout, which should include resilience to differences
> (and bugs) in the environment in which a document is read. This particular
> case may be uncommon, but there are other issues which could or do affect
> the stability of existing layouts:
> 
> - opentype kerning: an earlier post said that scribus doesn't yet support
> kerning of some opentype fonts. What happens to documents using them when
> it does?
> 

Then don't use OpenType fonts where we don't support kerning yet. IMO
providing kerning is more 
important than layout stability.



> - font upgrades: are font version updates guaranteed to keep all the same
> metrics? Otherwise font package upgrades could cause the same problem
> (this also applies to sharing documents across platforms/distributions)
> - scribus 1.2 and 1.3 have different algorithms for determining the
> spacing above the first line of text in a frame, leading to layout changes
> on scribus upgrades
> - other changes to come in the 1.3.4+ new layout engine...
> 
> ...etc. Some of these may seem picky, but again isn't precise control the
> strength of DTP? Especially for long documents, subtle changes in text
> rendering could cause undetected layout problems later in the document,
> such as text overflowing the allotted space. There could likewise be
> problems with tightly-fitted text no longer fitting in many small frames,
> which would be tedious to fix. Do other people agree that this is
> important? Some suggestions to address this:
> 
> - tracking versions of fonts used in documents, if this isn't done already
> - storing the effective font metric information used to create a layout in
> the document file
> 

I don't think we will go that far. Collect-for-output already bundles the
used fonts, so that should be enough.



> - storing the version of the layout algorithm used for text
> - when a document is loaded, if any subsystem has been upgraded/differs
> from the versions stored in the file, prompt to convert them or continue
> using the original layout
> 

Maybe that's a good occasion to explain my plans concerning NLS and layout
stability:

* Scribus will support the legacy layout algorithm in addition to the new
NLS layout algorithm. In fact I've already put quite some work into
isolating the old layout code to make that merge possible.
* The user can change the layout algorithm both ways. New docs have the NLS
version as default, old files will have the legacy version as default
* There already are changes to the legacy code which might break layout
stability. One is the fixing of a bug where hyphens were not properly
rightaligned in full lines. I'm not sure if this can change linebreaking,
but I don't think we'll provide a compatibility mode for this.
* The second change is optical margins. This is mandatory in 1.3.4cvs and
will become an option later. I'm not sure if optical margins should be on by
default for new docs, but it will be off for old docs in any case.
* Another change I have in mind is glyph extension, that's a 1-2% change in
horizontal scaling. This might change linebreaks when shrinking glyphs, but
not when extending glyphs. So for old files Scribus will only
extend glyphs when needed, for new files it will also shrink.
* Furthermore I'll probably introduce configurable word tracking, i.e.
changing the default size of blanks. This will definitely change linebreaks,
so the default for old files will be the nominal blank width.

Another thing which influences linebreaking is hyphenation and the
hyphenation dictionaries. Currently Scribus stores the used hyphenation
possibilities in the file, so these could be used to recreate the old
layout. I'm not sure yet as how to store this information in the new
fileformat, but we'll keep layout stability in mind.

To summarize: we will provide a legacy mode which ensures layout stability
for 1.2.x and 1.3.3.x files.
Layout will *not* be stable for 1.3.4 / 1.3.5 files. If everything works
well, layout will be stable again from 
1.3.6 on. We just need some flexibility in the 1.3.4 / 1.3.5 development
versions in order to test the new 
layout code and settle on an optimal solution.

I hope that sounds acceptable to you. Regarding your original concern about
Freetype and font metrics: 
I don't think we can do very much there. Freetype bugs are Freetype's bugs
and it's the user's task 
to make sure that the correct font (including correct version) is used.

Cheers
/Andreas

-- 
View this message in context: http://www.nabble.com/some-layout-stability-concerns-from-freetype-kerning-bug-tf2217538.html#a6143742
Sent from the Scribus forum at Nabble.com.