Re: Using Just the Font Metrics Stuff From FOP
Glen Mazza wrote: Yes, an explanation in Bugzilla on what the patches are for (I haven't been following the thread, and if it takes some weeks to be applied, no one will remember what they're for.) You're welcome to provide a link to the FOP archives to cut down on re-typing. Ok - Ive added links to the archives. Chris
Re: Using Just the Font Metrics Stuff From FOP
Eliot Kimber wrote: Ok, I have submitted bugs 25997 and 25999 with my patches to the maintenance and development branches. I tested this code by running both braches against my CFF OpenType font and a TTF font on my machine and inspecting the generated XML files. Let me know if you need more from me on these patches. Thanks for all your effort here Eliot. Chris
Re: Using Just the Font Metrics Stuff From FOP
--- Eliot Kimber <[EMAIL PROTECTED]> wrote: > Let me know if you need more from me on these > patches. > > Cheers, > > Eliot Yes, an explanation in Bugzilla on what the patches are for (I haven't been following the thread, and if it takes some weeks to be applied, no one will remember what they're for.) You're welcome to provide a link to the FOP archives to cut down on re-typing. Thanks, Glen __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
Re: Using Just the Font Metrics Stuff From FOP
Eliot Kimber wrote: Ok, I was able to patch the maint files as well (for real this time) and both it and the head seem to work fine, which I would expect since all my code really does is not read a couple of tables if the font is OpenType CFF. I will prepare diffs forthwith. Ok, I have submitted bugs 25997 and 25999 with my patches to the maintenance and development branches. I tested this code by running both braches against my CFF OpenType font and a TTF font on my machine and inspecting the generated XML files. Let me know if you need more from me on these patches. Cheers, Eliot -- W. Eliot Kimber Professional Services Innodata Isogen 9030 Research Blvd, #410 Austin, TX 78758 (512) 372-8122 [EMAIL PROTECTED] www.innodata-isogen.com
Re: Using Just the Font Metrics Stuff From FOP
Eliot Kimber wrote: Doh! It appears that I was developing against the head and not the maint branch--not sure how that happened. I'm looking now to see if my head code can be quickly retrofitted to the maint branch. Ok, I was able to patch the maint files as well (for real this time) and both it and the head seem to work fine, which I would expect since all my code really does is not read a couple of tables if the font is OpenType CFF. I will prepare diffs forthwith. Sorry for the confusion. Cheers, E. -- W. Eliot Kimber Professional Services Innodata Isogen 9030 Research Blvd, #410 Austin, TX 78758 (512) 372-8122 [EMAIL PROTECTED] www.innodata-isogen.com
RE: Using Just the Font Metrics Stuff From FOP
> -Original Message- > From: Eliot Kimber [mailto:[EMAIL PROTECTED] > > Doh! It appears that I was developing against the head and not the maint > branch--not sure how that happened. Did you run the diff w/o using any tags in particular? IIC if you don't, cvs runs a diff against the last version of the modified files in HEAD (= main development line). Cheers, Andreas
Re: Using Just the Font Metrics Stuff From FOP
Eliot Kimber wrote: Clay Leeds wrote: It's just a thought (and I'm not trying to look a gift-horse in the mouth! :-)), but perhaps you could work with those working on the HEAD branch, to make a unified diff for all changed file against HEAD. It appears that the relevant files are identical in the HEAD and maint branches. Doh! It appears that I was developing against the head and not the maint branch--not sure how that happened. I'm looking now to see if my head code can be quickly retrofitted to the maint branch. Cheers, E. -- W. Eliot Kimber Professional Services Innodata Isogen 9030 Research Blvd, #410 Austin, TX 78758 (512) 372-8122 [EMAIL PROTECTED] www.innodata-isogen.com
RE: Using Just the Font Metrics Stuff From FOP
> -Original Message- > From: Eliot Kimber [mailto:[EMAIL PROTECTED] > > > It appears that the relevant files are identical in the HEAD and maint > branches. > Could be... After all, fonts were next on the redesign schedule. It definitely will not hurt to enter the patch anyway. Just to give you the whole command for the diff: cvs -d :pserver:etc. -q diff -wu xml-fop ^^ (don't know this one by heart yet, sorry ;) ) I just seem to remember someone pointing out 'not to forget the -q option', and since that wasn't specified in the previous answers... Thanks again (in advance) for your input/effort! Cheers, Andreas
Re: Using Just the Font Metrics Stuff From FOP
Clay Leeds wrote: It's just a thought (and I'm not trying to look a gift-horse in the mouth! :-)), but perhaps you could work with those working on the HEAD branch, to make a unified diff for all changed file against HEAD. It appears that the relevant files are identical in the HEAD and maint branches. Cheers, E. -- W. Eliot Kimber Professional Services Innodata Isogen 9030 Research Blvd, #410 Austin, TX 78758 (512) 372-8122 [EMAIL PROTECTED] www.innodata-isogen.com
Re: Using Just the Font Metrics Stuff From FOP
From "man diff" SYNOPSIS diff [options] from-file to-file .. OPTIONS .. -u Use the unified output format. The command I use to generate a unified diff is: diff -u from-file to-file I'm guessing (as I'm no CVS or diff expert!) you'll have to do this for each file unless you somehow can have the from-file and to-file point to directories instead. I hope this helps! Web Maestro Clay On Jan 8, 2004, at 8:08 AM, Eliot Kimber wrote: Chris Bowditch wrote: Eliot Kimber wrote: Since the OpenType font metrics wouldn't include the kerning I don't know if it would be useful for full FOP, but it should be sufficient to allow basic font metrics for CFF OpenType fonts. Sounds good, i'm sure it will be useful for FOP even within kerning. Cool. Could you created a unified diff for all the changed files, raise a bug in Bugzilla, attach the patch file and give the bug a title prefixed with [PATCH]? The FOP team are grateful for your efforts here. I'm not sure what it means to create a unified diff--that's not something I've ever really done--I assume it's just a way of using CVS's diff utility to create a patch file. Can y'all point me in the right direction? Thanks, E. -- W. Eliot Kimber Professional Services Innodata Isogen 9030 Research Blvd, #410 Austin, TX 78758 (512) 372-8122 [EMAIL PROTECTED] www.innodata-isogen.com
Re: Using Just the Font Metrics Stuff From FOP
Chris Bowditch wrote: Eliot Kimber wrote: Since the OpenType font metrics wouldn't include the kerning I don't know if it would be useful for full FOP, but it should be sufficient to allow basic font metrics for CFF OpenType fonts. Sounds good, i'm sure it will be useful for FOP even within kerning. Cool. Could you created a unified diff for all the changed files, raise a bug in Bugzilla, attach the patch file and give the bug a title prefixed with [PATCH]? The FOP team are grateful for your efforts here. I'm not sure what it means to create a unified diff--that's not something I've ever really done--I assume it's just a way of using CVS's diff utility to create a patch file. Can y'all point me in the right direction? Thanks, E. -- W. Eliot Kimber Professional Services Innodata Isogen 9030 Research Blvd, #410 Austin, TX 78758 (512) 372-8122 [EMAIL PROTECTED] www.innodata-isogen.com
Re: Using Just the Font Metrics Stuff From FOP
Sorry about the fragment at the end of the main paragraph I wrote below (darned TouchPad on my laptop is too sensitive... erm.. and I wasn't paying close enough attention). Anyway, I don't have anything to add... On Jan 8, 2004, at 6:50 AM, Clay Leeds wrote: Eliot Kimber wrote: I haven't had a chance yet to test this with the XML font data-based font metrics because it's the end of the day and now I can't find the font metrics class that would apply (as opposed to the AWTFontMetrics class). Let me know if I should provide patches to someone. I used the 0.20.2-maintenance code as my base. It's just a thought (and I'm not trying to look a gift-horse in the mouth! :-)), but perhaps you could work with those working on the HEAD branch, to make a unified diff for all changed file against HEAD. That way we can be certain all the code you've created works and cause no problems under HEAD--the official development branch of FOP (0.20.2-maintenance is under a code-freeze which is apparently about to thaw a little bit). I think it would be best if you personally helped get your code into HEAD now, while everything is still fresh in our minds. Then again, not being much of a Java coder, your code could be ready for insertion into HEAD already. (there was supposed to be a period there... not the remaining portion of a thought process!) Web Maestro Clay
Re: Using Just the Font Metrics Stuff From FOP
Eliot (mostly), On Jan 8, 2004, at 1:24 AM, Chris Bowditch wrote: Eliot Kimber wrote: Since the OpenType font metrics wouldn't include the kerning I don't know if it would be useful for full FOP, but it should be sufficient to allow basic font metrics for CFF OpenType fonts. Sounds good, i'm sure it will be useful for FOP even within kerning. I haven't had a chance yet to test this with the XML font data-based font metrics because it's the end of the day and now I can't find the font metrics class that would apply (as opposed to the AWTFontMetrics class). Let me know if I should provide patches to someone. I used the 0.20.2-maintenance code as my base. It's just a thought (and I'm not trying to look a gift-horse in the mouth! :-)), but perhaps you could work with those working on the HEAD branch, to make a unified diff for all changed file against HEAD. That way we can be certain all the code you've created works and cause no problems under HEAD--the official development branch of FOP (0.20.2-maintenance is under a code-freeze which is apparently about to thaw a little bit). I think it would be best if you personally helped get your code into HEAD now, while everything is still fresh in our minds. Then again, not being much of a Java coder, your code could be ready for insertion into HEAD already, in which case, a unified PATCH for HEAD would be Could you created a unified diff for all the changed files, raise a bug in Bugzilla, attach the patch file and give the bug a title prefixed with [PATCH]? The FOP team are grateful for your efforts here. Clay - looks like I spoke too soon, there may be more patches that could easily be put into a 0.20.5.1 release. You're forgiven Chris, as it appears to have been written after your previous message :-).
Re: Using Just the Font Metrics Stuff From FOP
Eliot Kimber wrote: Since the OpenType font metrics wouldn't include the kerning I don't know if it would be useful for full FOP, but it should be sufficient to allow basic font metrics for CFF OpenType fonts. Sounds good, i'm sure it will be useful for FOP even within kerning. I haven't had a chance yet to test this with the XML font data-based font metrics because it's the end of the day and now I can't find the font metrics class that would apply (as opposed to the AWTFontMetrics class). Let me know if I should provide patches to someone. I used the 0.20.2-maintenance code as my base. Could you created a unified diff for all the changed files, raise a bug in Bugzilla, attach the patch file and give the bug a title prefixed with [PATCH]? The FOP team are grateful for your efforts here. Clay - looks like I spoke too soon, there may be more patches that could easily be put into a 0.20.5.1 release. Chris
Re: Using Just the Font Metrics Stuff From FOP
Eliot Kimber wrote: Jeremias Maerki wrote: The OpenType reader code is in TTFReader. OpenType is an evolution of TrueType. OK, I had to hack the TTFReader, TTFFile, and FontFileReader classes to handle the case of OpenType fonts that use CFF rather than TrueType for glyph information. There are tables that are not used by CFF fonts so I had to capture the version value and condition the processing of the loca, glyf, and kerning tables. I also added a getTagString() method to TTFDirTabEntry so I could write out the list of tables with readable tag names for debugging. In CFF fonts, the kerning table is replaced by the more sophisticated glyph positioning table (GPOS). This table would need to be processed in order to provide CFF-related kerning information, which is certainly beyond what I can do at the moment (if at all, although it can't be that hard). So now I can generate a font metrics file (without kerning info) for my CFF-based OpenType font. Since the OpenType font metrics wouldn't include the kerning I don't know if it would be useful for full FOP, but it should be sufficient to allow basic font metrics for CFF OpenType fonts. I haven't had a chance yet to test this with the XML font data-based font metrics because it's the end of the day and now I can't find the font metrics class that would apply (as opposed to the AWTFontMetrics class). Let me know if I should provide patches to someone. I used the 0.20.2-maintenance code as my base. Cheers, Eliot -- W. Eliot Kimber Professional Services Innodata Isogen 9030 Research Blvd, #410 Austin, TX 78758 (512) 372-8122 [EMAIL PROTECTED] www.innodata-isogen.com
Re: Using Just the Font Metrics Stuff From FOP
Eliot Kimber wrote: Cool--what tag do I use to checkout the 0.20.5? I'm not sure I completely understood what the FOP CVS information was telling me. The tag you need is: fop-0_20_2-maintain Chris
Re: Using Just the Font Metrics Stuff From FOP
Jeremias Maerki wrote: The OpenType reader code is in TTFReader. OpenType is an evolution of TrueType. Maybe you could try to use the TTFReader from 0.20.5. The HEAD TTFReader should be at least equal in functionality but I can't be sure we got all fixes for 0.20.5 into HEAD already. Cool--what tag do I use to checkout the 0.20.5? I'm not sure I completely understood what the FOP CVS information was telling me. Thanks, Eliot -- W. Eliot Kimber Professional Services Innodata Isogen 9030 Research Blvd, #410 Austin, TX 78758 (512) 372-8122 [EMAIL PROTECTED] www.innodata-isogen.com
Re: Using Just the Font Metrics Stuff From FOP
The OpenType reader code is in TTFReader. OpenType is an evolution of TrueType. Maybe you could try to use the TTFReader from 0.20.5. The HEAD TTFReader should be at least equal in functionality but I can't be sure we got all fixes for 0.20.5 into HEAD already. Good luck! On 07.01.2004 02:12:38 Eliot Kimber wrote: > I tried the TTFReader on my OpenType font and it died in ReadGlyf() :-( > > I see in a message from Victor Mote from July of 2003 that he had an > OpenType reader working but not committed. Is the OpenType reader code > available or has the OpenType support been pushed to somewhere else? Jeremias Maerki
Re: Using Just the Font Metrics Stuff From FOP
Eliot Kimber wrote: include all the TrueType fonts. It appears that Java 1.4 includes OpenType support but 1.4 is not an option for me at the moment. I tried the TTFReader on my OpenType font and it died in ReadGlyf() :-( I see in a message from Victor Mote from July of 2003 that he had an OpenType reader working but not committed. Is the OpenType reader code available or has the OpenType support been pushed to somewhere else? Thanks, Eliot -- W. Eliot Kimber Professional Services Innodata Isogen 9030 Research Blvd, #410 Austin, TX 78758 (512) 372-8122 [EMAIL PROTECTED] www.innodata-isogen.com
Re: Using Just the Font Metrics Stuff From FOP
Eliot Kimber wrote: Andreas L. Delmelle wrote: Hope this helps! It did. If I understand what AWTFontMetrics is doing, I can just use that class directly, or adapt that code for more standalone use. I will explore that route. This turned out to be much easier than I realized, at least for non-OpenType fonts. I now have a simple Saxon extension class that appears to return reasonable results for various fonts. However, it appears that OpenType fonts are not supported by the Java 1.3.1 AWT stuff, at least this call: Font[] fonts = GraphicsEnvironment.getLocalGraphicsEnvironment().getAllFonts(); results in a list that does not include my OpenType font but does include all the TrueType fonts. It appears that Java 1.4 includes OpenType support but 1.4 is not an option for me at the moment. Thanks for the help. Cheers, Eliot -- W. Eliot Kimber Professional Services Innodata Isogen 9030 Research Blvd, #410 Austin, TX 78758 (512) 372-8122 [EMAIL PROTECTED] www.innodata-isogen.com
Re: Using Just the Font Metrics Stuff From FOP
Eliot Kimber wrote: Here's my problem: during XSLT processing to generate FO instances I need to be able to make a reasonable guess as to the rendered length of a given string so that I can do some simple automatic copy fitting, such as setting the list label width to fit the longest item in a definition list. I know this can't be exact because of variables like kerning and justification, but in the normal case of unjustified, relatively short strings I should be able to get within an Em width of the correct length. I think I should be able to do this using the font metric support in the current development version of FOP but I'm having a hard time figuring out exactly what bits are involved. If you like contorted XSLT and abysmal performance, just use the metric XML files directly. The content should be fairly obvious. J.Pietschmann
Re: Using Just the Font Metrics Stuff From FOP
Andreas L. Delmelle wrote: Hope this helps! It did. If I understand what AWTFontMetrics is doing, I can just use that class directly, or adapt that code for more standalone use. I will explore that route. Thanks, Eliot -- W. Eliot Kimber Professional Services Innodata Isogen 9030 Research Blvd, #410 Austin, TX 78758 (512) 372-8122 [EMAIL PROTECTED] www.innodata-isogen.com
RE: Using Just the Font Metrics Stuff From FOP
> -Original Message- > From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] > > I think the explanation of registering the fonts contains just Ahem... incorrect estimate. More like --well, the metrics stuff :) Cheers, Andreas
RE: Using Just the Font Metrics Stuff From FOP
> -Original Message- > From: Eliot Kimber [mailto:[EMAIL PROTECTED] > > I think where I'm stuck is on what code actually takes a font and > generates a metrics file from it. I've traced down to where the XML > font metrics files are loaded but it appears that the font metrics files just exist. Hi, Check: http://xml.apache.org/fop/fonts.html I think the explanation of registering the fonts contains just the info you need (location of the classes generating metrics for Type1 / TrueType). Hope this helps! Cheers, Andreas
Using Just the Font Metrics Stuff From FOP
Here's my problem: during XSLT processing to generate FO instances I need to be able to make a reasonable guess as to the rendered length of a given string so that I can do some simple automatic copy fitting, such as setting the list label width to fit the longest item in a definition list. I know this can't be exact because of variables like kerning and justification, but in the normal case of unjustified, relatively short strings I should be able to get within an Em width of the correct length. I think I should be able to do this using the font metric support in the current development version of FOP but I'm having a hard time figuring out exactly what bits are involved. I think where I'm stuck is on what code actually takes a font and generates a metrics file from it. I've traced down to where the XML font metrics files are loaded but it appears that the font metrics files just exist. Also, I need to be able to process OpenType fonts and it's not clear from the code and the archives whether that's currently implemented, although I did see a couple messages discussing it. What I want to implement is an XSLT extension function something like this: public static int renderedStringLength(String str, String fontFamilyName, int fontSize) { Font font = magicFopFontHelper.getFont(fontFamilyName, fontSize); return font.getWordWidth(str); } Obviously, it's the "magicFopFontHelper" class that I'm not sure how to go about constructing. Can someone point me in the right direction? Thanks, Eliot -- W. Eliot Kimber Professional Services Innodata Isogen 9030 Research Blvd, #410 Austin, TX 78758 (512) 372-8122 [EMAIL PROTECTED] www.innodata-isogen.com