[Scribus] some layout stability concerns from freetype kerning bug

[Michael Koren]

avox wrote:
> 
> 
> 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.
> 

Could there be some kind of warning when selecting such a font so it's not
used unknowingly?



> 
> 
>> - 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.
> 

I was thinking of non-professional users who might upgrade their
distribution (including fonts) and not think about it/realize the difference
(but still don't want their documents unknowingly messed up).



> 
> 
>> - 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
> 

That's great, I had wondered about that.



> * 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.
> 

Interesting, nice enhancements. Incidentally, will these options be
per-document or per-parargaph/character? I can see wanting to set some of
those selectively.



> 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.
> 

Sounds good. Does that include the 1.2 -> 1.3 changes as I mentioned above?



> 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.
> 

Of course, so long as we all know. ;)



> 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.
> 

Thanks for the detailed reply. It sounds like you've got things under
control. :) My only suggestions would be to make sure there are warnings
where appropriate when something isn't supported yet, and maybe at least
store the font version? It wouldn't be that hard; it could be once per font
in the document, and advanced users could ask to see a warning if it doesn't
match their installed version just like if a font isn't available.



> Cheers
> /Andreas
> 

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