On Tue, May 28, 2013 at 9:59 AM, Ulrich Mayring <u...@denic.de> wrote:
> Thanks a lot guys for the information. I noticed the new feature Complex > Scripts, but did not look at it more closely, because I thought it would > not apply to me using plain English :) > > I have turned the feature off for now, which not only got rid of the > ligatures, it has also fixed the kerning for numbers, such as postal codes, > dates and account numbers. With the Complex Scripts feature on these > numbers are basically rendered in a monospaced way, which looks real ugly > in most places. Not sure which of the features mentioned are responsible > for that strange kerning (or lack thereof). > Actually, that may be due to another registered bug on my hit list: https://issues.apache.org/jira/browse/FOP-2213 > > I cannot use any of the suggested workarounds, because the text I process > is in parts dynamically generated and outside of my control. It would of > course be great if it were possible to enable/disable the various Complex > Scripts features independent of each other, preferably not just globally, > but on a per-paragraph level. > This would be possible if we introduce an fox:font-feature-settings property as defined in [3] cited below, or at least if they add a generic 'none' or 'off' value that disables all features. However, I doubt you would ever want to disable all font features, but rather would prefer to control them on a feature by feature basis, as presently defined in [3]. For example, you could specify: <fo:block fox:font-feature-setting="'liga' off"> Disable common ligature substitutions for 'ff', 'fi', 'fl', 'ffi', 'ffl', etc. </fo:block> I think it probably undesirable to turn of CS on a block basis, though that could probably be implemented as well without undue difficulty. I've added a couple of "New Feature" issues on these items: https://issues.apache.org/jira/browse/FOP-2256 https://issues.apache.org/jira/browse/FOP-2257 > > Kind regards, > > Ulrich > > > Glenn Adams wrote: > >> The addition of Complex Script support in FOP 1.1 is the cause. The font >> actually controls whether ligatures are used or not. >> >> The following features are enabled by default for all scripts which do not >> otherwise override this feature set: >> >> GSUB: {ccmp, liga, locl} >> GPOS: {kern, mark, mkmk} >> >> See org.apache.fop.complexscripts.**scripts.**DefaultScriptProcessor. >> >> If you read the description of these features [1], you will find that they >> are defined as "should be active by default". >> >> [1] >> http://www.microsoft.com/**typography/otspec/featurelist.**htm<http://www.microsoft.com/typography/otspec/featurelist.htm> >> >> So, if a font designer includes a 'liga' table in the font, then those >> substitutions will apply. As Pascal has pointed out, you can disable CS >> entirely, in which case none of the GSUB or GPOS processing is performed. >> Another work around would be to use something like: >> >> <fo:character character="f"/><fo:character character="i"/> >> >> which happens to work at the moment due to a bug that prevents performing >> GSUB processing across an element boundary, but that may be fixed at some >> point. >> >> A better long term solution is to introduce the CSS3 Font Module's >> font-variant-ligatures property [2], or, more generally, the >> font-feature-settings property [3] as "fox:" extension attributes. >> >> [2] >> http://www.w3.org/TR/css3-**fonts/#font-variant-ligatures-**prop<http://www.w3.org/TR/css3-fonts/#font-variant-ligatures-prop> >> [3] >> http://www.w3.org/TR/css3-**fonts/#font-feature-settings-**prop<http://www.w3.org/TR/css3-fonts/#font-feature-settings-prop> >> >> Regards, >> Glenn >> >> >> >> On Tue, May 28, 2013 at 3:01 AM, Ulrich Mayring <u...@denic.de> wrote: >> >> Hi all, >>> >>> I just upgraded from 0.95 to 1.1 and one of the issues that crept up is >>> that suddenly FOP uses ligatures, which it did not use before. Latin >>> words >>> containing the letters "fi" or "fl" are now rendered using ligatures in >>> the >>> PDF, although they are written as two seperate characters in the XML >>> input >>> file. >>> >>> I can open a bug and/or supply concrete test cases if needed, but I just >>> wanted to ask beforehand whether that is a known problem or perhaps a >>> configuration option? >>> >>> I am using a TrueType font, Pragmatica Condensed. It may well have to do >>> with this font, since the standard FOP examples do not seem to have this >>> problem. >>> >>> Many thanks in advance for any pointers, >>> >>> Ulrich >>> >>> >>> ------------------------------****----------------------------** >>> --**--------- >>> To unsubscribe, e-mail: >>> fop-users-unsubscribe@**xmlgra**phics.apache.org<http://xmlgraphics.apache.org> >>> <fop-users-**unsubscribe@xmlgraphics.**apache.org<fop-users-unsubscr...@xmlgraphics.apache.org> >>> > >>> For additional commands, e-mail: fop-users-help@xmlgraphics.**a** >>> pache.org >>> <http://apache.org><fop-users-help@**xmlgraphics.apache.org<fop-users-h...@xmlgraphics.apache.org> >>> > >>> >>> >>> >> > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > fop-users-unsubscribe@**xmlgraphics.apache.org<fop-users-unsubscr...@xmlgraphics.apache.org> > For additional commands, e-mail: > fop-users-help@xmlgraphics.**apache.org<fop-users-h...@xmlgraphics.apache.org> > >
