Re: Kerning and hyphenation
On 13.01.2007 06:32:15 Manuel Mall wrote: While looking into the support for the Soft Hyphen the area of hyphenation combined with kerning is causing me trouble. Aside 1: our fonts page claims we don't support kerning but I believe we do. Yes, we do. Aside 2: Our tests are based on setting the base14kerning flag. I don't think this flag is documented anywhere on the fop site. Can it be set in the config file? Not yet, no, only through the FopFactory. I wrote a simple test under fop 0.93 and noticed that the ipd of text areas with the combination of kerning and hyphenation are not correctly calculated (at least I think so). With the Base 14 sans-serif font at 20pt we get: Word vanda alone on a line: ipd=53980 Word vandavanda alone on a line: ipd=107560 (53980+53980-400) Word vandavandavanda alone on a line: ipd=161140 (53980+53980+53980-400-400) If we now take the word vandavandavandavanda and get it hyphenated after the 3rd vanda the line containing vandavandavanda- reports an ipd of 168800 which is incorrect. I think it should be 161140 + 6660 (width of hyphen) = 167800. I think you mean it is 168600 (that's what I get) and it should be 167800, which is a difference of 800mpt. 800mpt looks much like two times 400mpt kerning which are not removed from the area objects's IPD for the break at a hyphenation point. However, I'd expect a difference of only 400mpt, not 800mpt. I did fix [1] the behaviour for that condition so the layout looks correct, but apparently I didn't adjust the IPD for the area object. [1] http://svn.apache.org/viewvc?rev=407774view=rev Before I investigate this more can someone else check this and see if they get similar results. I have attached the test case I have constructed. Manuel Jeremias Maerki
Re: Kerning for CID fonts, use unicode indexes in kerning?
Thanks for the changes. I understand the necessity now. I've done some tests and after your latest fix, everything seems to be working fine. Let's hope our users won't be too mad at us for changing the format. I have some time in trains this and next week. Maybe I'll try to figure out if it's a small change to bypass the metrics file entirely. :-) Actually, finishing my DataMatrix implementation is more important but if this were only a small step we should take it. *g* Otherwise, we'll defer that to the FOray stuff. On 12.10.2006 12:17:36 Bertrand Delacretaz wrote: On 10/11/06, Jeremias Maerki [EMAIL PROTECTED] wrote: ...I wonder how much should be invested in versioning of those files Ok, so I have added a simplistic versioning system for these metrics XML files, an exception is thrown when attempting to read incompatible metrics files (http://issues.apache.org/bugzilla/show_bug.cgi?id=40739). Mapping the glyph indexes to unicode indexes when reading the XML metrics file seemed more complicated than when creating the file, so I have implemented the change in the TTFFile class, which now writes the kerning info based on unicode code points. A note in the FOray release notes (http://foray.sourceforge.net/app/using/release.html) says Kerning has been fixed for subsetted fonts, makes me wonder if kerning did work before for custom CID fonts. Anyway it should work now. -Bertrand Jeremias Maerki
Re: Kerning for CID fonts, use unicode indexes in kerning?
On 10/13/06, Jeremias Maerki [EMAIL PROTECTED] wrote: ...Maybe I'll try to figure out if it's a small change to bypass the metrics file entirely. :-) Shouldn't be hard at all, but right now I have to create a test document to demonstrate the new font features for my own project, so I won't be able to do it ATM. I hear you work well on trains ;-) -Bertrand
Re: Kerning for CID fonts, use unicode indexes in kerning?
Right, it isn't hard. Almost works after a train ride to Zurich and back. :-) On 13.10.2006 11:33:09 Bertrand Delacretaz wrote: On 10/13/06, Jeremias Maerki [EMAIL PROTECTED] wrote: ...Maybe I'll try to figure out if it's a small change to bypass the metrics file entirely. :-) Shouldn't be hard at all, but right now I have to create a test document to demonstrate the new font features for my own project, so I won't be able to do it ATM. I hear you work well on trains ;-) -Bertrand Jeremias Maerki
Re: Kerning for CID fonts, use unicode indexes in kerning?
On 10/11/06, Jeremias Maerki [EMAIL PROTECTED] wrote: ...I wonder how much should be invested in versioning of those files Ok, so I have added a simplistic versioning system for these metrics XML files, an exception is thrown when attempting to read incompatible metrics files (http://issues.apache.org/bugzilla/show_bug.cgi?id=40739). Mapping the glyph indexes to unicode indexes when reading the XML metrics file seemed more complicated than when creating the file, so I have implemented the change in the TTFFile class, which now writes the kerning info based on unicode code points. A note in the FOray release notes (http://foray.sourceforge.net/app/using/release.html) says Kerning has been fixed for subsetted fonts, makes me wonder if kerning did work before for custom CID fonts. Anyway it should work now. -Bertrand
Re: Kerning for CID fonts, use unicode indexes in kerning?
I wonder where this got broken. I believe this used to work. If this change has an effect on the XML files generated, then we should be careful because people might not recreate their metric files and subsequently run into problems. On 11.10.2006 13:15:54 Bertrand Delacretaz wrote: Hi FOPpers, See http://issues.apache.org/bugzilla/show_bug.cgi?id=40724 , kerning doesn't work for me with user-specified CID fonts at the moment. IIUC the code, org.apache.fop.layoutmgr.inline.TextLayoutManager expects unicode indexes for kerning pairs, but currently the TTFReader writes glyph indexes in the XML file, like: kerning kpx1=3 pair kern=-279 kpx2=4/ /kerning Where 3 and 4 are glyph indexes (I'm playing with a test font with very few glyphs, it's easier). I've tried changing the TTFFile code to use unicode indexes for kpx1 and kpx2 and it seems to work - anything against making this change? -Bertrand Jeremias Maerki
Re: Kerning for CID fonts, use unicode indexes in kerning?
On 10/11/06, Jeremias Maerki [EMAIL PROTECTED] wrote: ...If this change has an effect on the XML files generated, then we should be careful because people might not recreate their metric files and subsequently run into problems... How about adding a version number to the XML metrics files? This would make them more future-proof, and in this case we could detect old files and bark. -Bertrand
Re: Kerning for CID fonts, use unicode indexes in kerning?
Sure. However, as we discussed in Amsterdam, the goal should be that we don't rely on those XML files much longer, so I wonder how much should be invested in versioning of those files. But if you don't see a way around it... I still don't understand why exactly this change is necessary. On 11.10.2006 18:59:07 Bertrand Delacretaz wrote: On 10/11/06, Jeremias Maerki [EMAIL PROTECTED] wrote: ...If this change has an effect on the XML files generated, then we should be careful because people might not recreate their metric files and subsequently run into problems... How about adding a version number to the XML metrics files? This would make them more future-proof, and in this case we could detect old files and bark. -Bertrand Jeremias Maerki
Letter space [was Re: Kerning]
[Luca] ... A little doubt concerning letter spaces: at the moment, a letter space is assigned to the preceding character. Is this correct? I don't remember any section in the specs stating about the ownership of letter spaces ... I think that everything is simpler, from the point of view of both users and implementors, if each letter space is owned by the preceding (or following) formatting object, but this does not mean it is what the specs require! In [7.16.2 letter-spacing], I read it as if each alphabetic letter has 1/2 a letter space preceding and 1/2 a letter space following the character. These space-before and space-after trait values are then resolved with whatever other spaces that they are up against according to space resolution rules. The same goes for wordspaces which is split into 2 half word spaces. A Word then becomes: hls 'A' hls hws hws hls 'W' hls hls 'o' hls hls 'r' hls hls 'd' hls where 'hls' is half a letter-space and 'hws' is half a word-space. How the hls hls and 'hls hws' sequences are resolved depends the .precedence and .conditionality values. OTOH, it is user agent dependant how letter space is resolved with word spaces, so I think your implementation is complient, it is just not what I think the spec suggest. regards, finn
Re: Kerning
Starting from your final summary: Manuel Mall wrote: IMO FOP should limit itself to: a) Use kerning only for consecutive characters within the same fo Ok, but more on this later in this message ... b) Limit itself to the kerning information in the font Ok c) Only apply kerning if the letter-spacing property has the value normal (and the font supports it) Isn't this condition too strong? I see kerning as an extra space, something that is added to the letter spacing, not something that replaces it. A simple example with our kerning couple AV: a) at the moment kerning is not implemented, so with normal letter-spacing the space between A and V seems bigger than the space between I and L, for example; b) we implement kerning, so the space between A and V is reduced and it visually looks like the space between I and L; c) what if we have a negative letter-spacing? if we don't apply kerning any more, we go back to a): the space between A and V would seem bigger than the space between I and L. In other words: if the kerning value stored in the font is correct, it should always be added to the letter spacing: it would make the characters overlap only when the letter-spacing alone would make normal characters overlap, and in this case this should be considered the desired output. In the end XSL-FO has the letter-spacing property which users (and programs generating XSL-FO) can use to adjust kerning. A little doubt concerning letter spaces: at the moment, a letter space is assigned to the preceding character. Is this correct? I don't remember any section in the specs stating about the ownership of letter spaces ... I think that everything is simpler, from the point of view of both users and implementors, if each letter space is owned by the preceding (or following) formatting object, but this does not mean it is what the specs require! An example: if we have the text WORD where each letter is a fo:character, the first three fo:character ATM have a letter space each, and the fourth has none. All is ok as long as the fo:characters have no (or equal) letter-spacing, but what if each fo:character has a different letter-spacing property the ouput is different according to the fo:characters controlling letter spaces. Regards Luca
RE: Kerning
Hi Luca. Its been over 15 years since I did any kerning, but, from what I remember, kerning isn't just left or right, its also up and down (and possibly other transforms/alterations for all I know). Consider the kerned symbols in the LATeX logo. The A is raised and snuggled between the L and the T. I know that this is a special case, however, its worth verifying that the only spacing differences for all kerns are left/right. I seem to remember that some characters (small i or j come to mind) lose their dots in certain circumstances as well - that may not be kerning, though - I don't remember, its been 15 years :-) All of this would be from the LATeX manual and related documentation (MetaFont?), of which I don't have handy. Thanks. Shannon Mann -Original Message- From: Luca Furini [mailto:[EMAIL PROTECTED] Sent: Friday, December 09, 2005 8:42 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: Kerning Starting from your final summary: Manuel Mall wrote: IMO FOP should limit itself to: a) Use kerning only for consecutive characters within the same fo Ok, but more on this later in this message ... b) Limit itself to the kerning information in the font Ok c) Only apply kerning if the letter-spacing property has the value normal (and the font supports it) Isn't this condition too strong? I see kerning as an extra space, something that is added to the letter spacing, not something that replaces it. A simple example with our kerning couple AV: a) at the moment kerning is not implemented, so with normal letter-spacing the space between A and V seems bigger than the space between I and L, for example; b) we implement kerning, so the space between A and V is reduced and it visually looks like the space between I and L; c) what if we have a negative letter-spacing? if we don't apply kerning any more, we go back to a): the space between A and V would seem bigger than the space between I and L. In other words: if the kerning value stored in the font is correct, it should always be added to the letter spacing: it would make the characters overlap only when the letter-spacing alone would make normal characters overlap, and in this case this should be considered the desired output. In the end XSL-FO has the letter-spacing property which users (and programs generating XSL-FO) can use to adjust kerning. A little doubt concerning letter spaces: at the moment, a letter space is assigned to the preceding character. Is this correct? I don't remember any section in the specs stating about the ownership of letter spaces ... I think that everything is simpler, from the point of view of both users and implementors, if each letter space is owned by the preceding (or following) formatting object, but this does not mean it is what the specs require! An example: if we have the text WORD where each letter is a fo:character, the first three fo:character ATM have a letter space each, and the fourth has none. All is ok as long as the fo:characters have no (or equal) letter-spacing, but what if each fo:character has a different letter-spacing property the ouput is different according to the fo:characters controlling letter spaces. Regards Luca - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
