OpenType font library [was: Re: How much work is needed for FOP to support OpenType fonts?]
I take this discussion to express my worries that FOP needs to create its own support for fonts, among which Open Type Fonts. FOP's core task is the layout and printing of FO files. If FOP could rely on good font libraries, that would make our code base so much smaller and our development tasks so much easier. If I am not mistaken, Firefox does a fairly good job at representing Indic scripts. Do they use a generally available library? Are there no such libraries? Or do I see the issue wrong? Regards, Simon On Tue, Jan 18, 2011 at 04:11:54PM -0700, Glenn Adams wrote: That is a better question, but one I cannot answer, as I have not looked into the CFF support issue. Perhaps another DEV would care to respond. On Tue, Jan 18, 2011 at 4:03 PM, Ivan Ristic ivan.ris...@gmail.com wrote: On Tue, Jan 18, 2011 at 10:51 PM, Glenn Adams gl...@skynav.com wrote: On Tue, Jan 18, 2011 at 3:41 PM, Ivan Ristic ivan.ris...@gmail.com wrote: On Tue, Jan 18, 2011 at 9:27 PM, Glenn Adams gl...@skynav.com wrote: What do you mean by fully? If you are referring to the OpenType GDEF, GSUB, GPOS support, then work is already underway to add that functionality. See the following for further info: http://people.apache.org/~spepping/ http://wiki.apache.org/xmlgraphics-fop/ComplexScripts
Re: How much work is needed for FOP to support OpenType fonts?
Hi Ivan, I've been looking quite a bit at the fonts packages recently, and you are correct neither CFF nor True Type collections are currently supported. They both need to be implemented. In terms of how long it would take, that's a very speculative question and not quite as simple to answer as it may seem. Mostly because it depends what you mean by supported? Which output format? Full font embedding or subset embedding? If you mean full font embedding, I don't think it would take very long assuming the person was familiar with the fonts packages, the FOP renderers and probably more importantly the PDF/PostScript and CFF specs. If you're not familiar with the terms I've used, full font embedding is fairly simple, it involves streaming the font byte for byte to the PDF document. In PostScript, it's a little more involved because you have to stream the font as an ASCII hexadecimal stream and break the string up (maximum size is 65535 chars) at table or glyph boundaries. Subset font embedding involves remembering which glyphs were actually used in the document and creating a subset of the font that include only those glyphs used and embedding the subset. The implications are that if you have a document with large fonts in, or a lot of different fonts, then full font embedding will bloat the file size, this may be so big that some printers (especially older ones with small memory sizes) may crash. Subset embedding does mean that you have smaller file sizes, but may cause issues if you have a print manager that holds fonts in memory for future use. I should prefix the above by saying I've only just peeked at CFF but luckily if you want full font embedding, you probably don't need to do much poking around in the CFF spec (only to get a feel of the format and what each table does), you'll need to spend more time in the PS/PDF spec. The Temp_TrueTypeInPostScript branch, has a patch associated with it, that I've been working on to support Full font and subset font embedding in the PostScript output format for TrueType fonts only, but the new architecture should make it much simpler to extend font support. So, if you mean supporting full font embedding of CFF in PostScript/PDF it shouldn't take too long. However, if you're looking for subset font embedding, this could take a bit longer (I wouldn't want to speculate on how long having not looked at the CFF spec in great detail). Time wise, most of it is going to be testing since if someone was to implement support for any font features, I'd very strongly suggest JUnit testing as a starting point. The reason being that fonts are quite complicated and introducing bugs is both easy to do and difficult to root out by simply looking at the final PDF/Postscript file. The next issue is having a testbed in order to test regression and ensure that changing a method doesn't break some feature for another font format. This may sound simple, but that means creating the FOs with foreign glyphs, CJK for example, is quite laborious. If you take a look at my patch (https://issues.apache.org/bugzilla/show_bug.cgi?id=50483), I've added JUnit tests for quite a few of the classes in the fonts package so that might help you get started. Time wise, most of it is going to be testing since if someone was to implement support for any font features, I'd very strongly suggest JUnit testing as a starting point. The reason being that fonts are quite complicated and introducing bugs is both easy to do and difficult to root out by simply looking at the final PDF/Postscript file. The next issue is having a testbed in order to test regression and ensure that changing a method doesn't break some feature for another font format. This may sound simple, but that means creating the FOs with foreign glyphs, CJK for example, is quite laborious. If you take a look at my patch (https://issues.apache.org/bugzilla/show_bug.cgi?id=50483), I've added JUnit tests for quite a few of the classes in the fonts package so that might help you get started. If you do start implementing this feature, don't hesitate to get in contact and I can try and share some of my knowledge and/or test-suite as an when you require it. Sorry for the verbosity of the email, as you'll find, fonts are not to be underestimated. Mehdi On 18 January 2011 23:11, Glenn Adams gl...@skynav.com wrote: That is a better question, but one I cannot answer, as I have not looked into the CFF support issue. Perhaps another DEV would care to respond. G. On Tue, Jan 18, 2011 at 4:03 PM, Ivan Ristic ivan.ris...@gmail.com wrote: On Tue, Jan 18, 2011 at 10:51 PM, Glenn Adams gl...@skynav.com wrote: Ivan, This type of question is best put to the FOP User fop-us...@xmlgraphics.apache.org email list rather than the developer list. Actually, I was offering (or considering) to give back some of the money FOP saved me (when I self-published my book). I don't think sending my offer to the users' list would be very useful. In any
Re: How much work is needed for FOP to support OpenType fonts?
Oops, I seem to have copy/pasted that link twice, my apologies, it probably doesn't deserve 2 mentions. Mehdi On 19 January 2011 09:17, mehdi houshmand med1...@gmail.com wrote: Hi Ivan, I've been looking quite a bit at the fonts packages recently, and you are correct neither CFF nor True Type collections are currently supported. They both need to be implemented. In terms of how long it would take, that's a very speculative question and not quite as simple to answer as it may seem. Mostly because it depends what you mean by supported? Which output format? Full font embedding or subset embedding? If you mean full font embedding, I don't think it would take very long assuming the person was familiar with the fonts packages, the FOP renderers and probably more importantly the PDF/PostScript and CFF specs. If you're not familiar with the terms I've used, full font embedding is fairly simple, it involves streaming the font byte for byte to the PDF document. In PostScript, it's a little more involved because you have to stream the font as an ASCII hexadecimal stream and break the string up (maximum size is 65535 chars) at table or glyph boundaries. Subset font embedding involves remembering which glyphs were actually used in the document and creating a subset of the font that include only those glyphs used and embedding the subset. The implications are that if you have a document with large fonts in, or a lot of different fonts, then full font embedding will bloat the file size, this may be so big that some printers (especially older ones with small memory sizes) may crash. Subset embedding does mean that you have smaller file sizes, but may cause issues if you have a print manager that holds fonts in memory for future use. I should prefix the above by saying I've only just peeked at CFF but luckily if you want full font embedding, you probably don't need to do much poking around in the CFF spec (only to get a feel of the format and what each table does), you'll need to spend more time in the PS/PDF spec. The Temp_TrueTypeInPostScript branch, has a patch associated with it, that I've been working on to support Full font and subset font embedding in the PostScript output format for TrueType fonts only, but the new architecture should make it much simpler to extend font support. So, if you mean supporting full font embedding of CFF in PostScript/PDF it shouldn't take too long. However, if you're looking for subset font embedding, this could take a bit longer (I wouldn't want to speculate on how long having not looked at the CFF spec in great detail). Time wise, most of it is going to be testing since if someone was to implement support for any font features, I'd very strongly suggest JUnit testing as a starting point. The reason being that fonts are quite complicated and introducing bugs is both easy to do and difficult to root out by simply looking at the final PDF/Postscript file. The next issue is having a testbed in order to test regression and ensure that changing a method doesn't break some feature for another font format. This may sound simple, but that means creating the FOs with foreign glyphs, CJK for example, is quite laborious. If you take a look at my patch (https://issues.apache.org/bugzilla/show_bug.cgi?id=50483), I've added JUnit tests for quite a few of the classes in the fonts package so that might help you get started. Time wise, most of it is going to be testing since if someone was to implement support for any font features, I'd very strongly suggest JUnit testing as a starting point. The reason being that fonts are quite complicated and introducing bugs is both easy to do and difficult to root out by simply looking at the final PDF/Postscript file. The next issue is having a testbed in order to test regression and ensure that changing a method doesn't break some feature for another font format. This may sound simple, but that means creating the FOs with foreign glyphs, CJK for example, is quite laborious. If you take a look at my patch (https://issues.apache.org/bugzilla/show_bug.cgi?id=50483), I've added JUnit tests for quite a few of the classes in the fonts package so that might help you get started. If you do start implementing this feature, don't hesitate to get in contact and I can try and share some of my knowledge and/or test-suite as an when you require it. Sorry for the verbosity of the email, as you'll find, fonts are not to be underestimated. Mehdi On 18 January 2011 23:11, Glenn Adams gl...@skynav.com wrote: That is a better question, but one I cannot answer, as I have not looked into the CFF support issue. Perhaps another DEV would care to respond. G. On Tue, Jan 18, 2011 at 4:03 PM, Ivan Ristic ivan.ris...@gmail.com wrote: On Tue, Jan 18, 2011 at 10:51 PM, Glenn Adams gl...@skynav.com wrote: Ivan, This type of question is best put to the FOP User fop-us...@xmlgraphics.apache.org email
Re: OpenType font library [was: Re: How much work is needed for FOP to support OpenType fonts?]
Hi Simon, The FOP font library doesn't actually render or paint any fonts, it does 1 of 2 things. Either it a) creates a subset of the font, and streams the subset (as a byte stream) to the PDF/PS document or b) it streams the whole font to the document (I think this is what is done for AFP, I don't think FOP supports subset embedding in AFP). This means the reader of the document has to read the font we embed and then does all the painting and rendering. Since Firefox is a viewer/browser and doesn't have a feature to embed fonts when saving html (or at least I'm pretty sure it doesn't) I'm not sure how we could take advantage of a graphics library, since that is done in the reader and not the document. OpenGL and SDL libraries are good examples of opensource programs that do display fonts, but again, I dont think subsetting/embedding is in their scope. I could however be completely mistaken but that's my tuppence worth. Mehdi On 19 January 2011 08:35, Simon Pepping spepp...@leverkruid.eu wrote: I take this discussion to express my worries that FOP needs to create its own support for fonts, among which Open Type Fonts. FOP's core task is the layout and printing of FO files. If FOP could rely on good font libraries, that would make our code base so much smaller and our development tasks so much easier. If I am not mistaken, Firefox does a fairly good job at representing Indic scripts. Do they use a generally available library? Are there no such libraries? Or do I see the issue wrong? Regards, Simon On Tue, Jan 18, 2011 at 04:11:54PM -0700, Glenn Adams wrote: That is a better question, but one I cannot answer, as I have not looked into the CFF support issue. Perhaps another DEV would care to respond. On Tue, Jan 18, 2011 at 4:03 PM, Ivan Ristic ivan.ris...@gmail.com wrote: On Tue, Jan 18, 2011 at 10:51 PM, Glenn Adams gl...@skynav.com wrote: On Tue, Jan 18, 2011 at 3:41 PM, Ivan Ristic ivan.ris...@gmail.com wrote: On Tue, Jan 18, 2011 at 9:27 PM, Glenn Adams gl...@skynav.com wrote: What do you mean by fully? If you are referring to the OpenType GDEF, GSUB, GPOS support, then work is already underway to add that functionality. See the following for further info: http://people.apache.org/~spepping/ http://wiki.apache.org/xmlgraphics-fop/ComplexScripts
Re: How much work is needed for FOP to support OpenType fonts?
Mehdi, TrueType collections are supported! On 19.01.2011 10:17:11 mehdi houshmand wrote: Hi Ivan, I've been looking quite a bit at the fonts packages recently, and you are correct neither CFF nor True Type collections are currently supported. They both need to be implemented. In terms of how long it would take, that's a very speculative question and not quite as simple to answer as it may seem. Mostly because it depends what you mean by supported? Which output format? Full font embedding or subset embedding? If you mean full font embedding, I don't think it would take very long assuming the person was familiar with the fonts packages, the FOP renderers and probably more importantly the PDF/PostScript and CFF specs. If you're not familiar with the terms I've used, full font embedding is fairly simple, it involves streaming the font byte for byte to the PDF document. In PostScript, it's a little more involved because you have to stream the font as an ASCII hexadecimal stream and break the string up (maximum size is 65535 chars) at table or glyph boundaries. Subset font embedding involves remembering which glyphs were actually used in the document and creating a subset of the font that include only those glyphs used and embedding the subset. The implications are that if you have a document with large fonts in, or a lot of different fonts, then full font embedding will bloat the file size, this may be so big that some printers (especially older ones with small memory sizes) may crash. Subset embedding does mean that you have smaller file sizes, but may cause issues if you have a print manager that holds fonts in memory for future use. I should prefix the above by saying I've only just peeked at CFF but luckily if you want full font embedding, you probably don't need to do much poking around in the CFF spec (only to get a feel of the format and what each table does), you'll need to spend more time in the PS/PDF spec. The Temp_TrueTypeInPostScript branch, has a patch associated with it, that I've been working on to support Full font and subset font embedding in the PostScript output format for TrueType fonts only, but the new architecture should make it much simpler to extend font support. So, if you mean supporting full font embedding of CFF in PostScript/PDF it shouldn't take too long. However, if you're looking for subset font embedding, this could take a bit longer (I wouldn't want to speculate on how long having not looked at the CFF spec in great detail). Time wise, most of it is going to be testing since if someone was to implement support for any font features, I'd very strongly suggest JUnit testing as a starting point. The reason being that fonts are quite complicated and introducing bugs is both easy to do and difficult to root out by simply looking at the final PDF/Postscript file. The next issue is having a testbed in order to test regression and ensure that changing a method doesn't break some feature for another font format. This may sound simple, but that means creating the FOs with foreign glyphs, CJK for example, is quite laborious. If you take a look at my patch (https://issues.apache.org/bugzilla/show_bug.cgi?id=50483), I've added JUnit tests for quite a few of the classes in the fonts package so that might help you get started. Time wise, most of it is going to be testing since if someone was to implement support for any font features, I'd very strongly suggest JUnit testing as a starting point. The reason being that fonts are quite complicated and introducing bugs is both easy to do and difficult to root out by simply looking at the final PDF/Postscript file. The next issue is having a testbed in order to test regression and ensure that changing a method doesn't break some feature for another font format. This may sound simple, but that means creating the FOs with foreign glyphs, CJK for example, is quite laborious. If you take a look at my patch (https://issues.apache.org/bugzilla/show_bug.cgi?id=50483), I've added JUnit tests for quite a few of the classes in the fonts package so that might help you get started. If you do start implementing this feature, don't hesitate to get in contact and I can try and share some of my knowledge and/or test-suite as an when you require it. Sorry for the verbosity of the email, as you'll find, fonts are not to be underestimated. Mehdi On 18 January 2011 23:11, Glenn Adams gl...@skynav.com wrote: That is a better question, but one I cannot answer, as I have not looked into the CFF support issue. Perhaps another DEV would care to respond. G. On Tue, Jan 18, 2011 at 4:03 PM, Ivan Ristic ivan.ris...@gmail.com wrote: On Tue, Jan 18, 2011 at 10:51 PM, Glenn Adams gl...@skynav.com wrote: Ivan, This type of question is best put to the FOP User fop-us...@xmlgraphics.apache.org email list rather than the developer list. Actually, I was offering
Re: How much work is needed for FOP to support OpenType fonts?
Jeremias, They are with your /GlyphDirectory mechanism, and for full font embedding but not for subsetting with the /sfnts in my patch. And the /GlyphDirectory system was causing issues with some printers (I think IBM printers if memory serves), so it depends what you mean by supported. You'll be able to view them and print them on most printers, but can't guarantee 100% compliance. Sorry if I didn't make that clear. Mehdi On 19 January 2011 09:55, Jeremias Maerki d...@jeremias-maerki.ch wrote: Mehdi, TrueType collections are supported! On 19.01.2011 10:17:11 mehdi houshmand wrote: Hi Ivan, I've been looking quite a bit at the fonts packages recently, and you are correct neither CFF nor True Type collections are currently supported. They both need to be implemented. In terms of how long it would take, that's a very speculative question and not quite as simple to answer as it may seem. Mostly because it depends what you mean by supported? Which output format? Full font embedding or subset embedding? If you mean full font embedding, I don't think it would take very long assuming the person was familiar with the fonts packages, the FOP renderers and probably more importantly the PDF/PostScript and CFF specs. If you're not familiar with the terms I've used, full font embedding is fairly simple, it involves streaming the font byte for byte to the PDF document. In PostScript, it's a little more involved because you have to stream the font as an ASCII hexadecimal stream and break the string up (maximum size is 65535 chars) at table or glyph boundaries. Subset font embedding involves remembering which glyphs were actually used in the document and creating a subset of the font that include only those glyphs used and embedding the subset. The implications are that if you have a document with large fonts in, or a lot of different fonts, then full font embedding will bloat the file size, this may be so big that some printers (especially older ones with small memory sizes) may crash. Subset embedding does mean that you have smaller file sizes, but may cause issues if you have a print manager that holds fonts in memory for future use. I should prefix the above by saying I've only just peeked at CFF but luckily if you want full font embedding, you probably don't need to do much poking around in the CFF spec (only to get a feel of the format and what each table does), you'll need to spend more time in the PS/PDF spec. The Temp_TrueTypeInPostScript branch, has a patch associated with it, that I've been working on to support Full font and subset font embedding in the PostScript output format for TrueType fonts only, but the new architecture should make it much simpler to extend font support. So, if you mean supporting full font embedding of CFF in PostScript/PDF it shouldn't take too long. However, if you're looking for subset font embedding, this could take a bit longer (I wouldn't want to speculate on how long having not looked at the CFF spec in great detail). Time wise, most of it is going to be testing since if someone was to implement support for any font features, I'd very strongly suggest JUnit testing as a starting point. The reason being that fonts are quite complicated and introducing bugs is both easy to do and difficult to root out by simply looking at the final PDF/Postscript file. The next issue is having a testbed in order to test regression and ensure that changing a method doesn't break some feature for another font format. This may sound simple, but that means creating the FOs with foreign glyphs, CJK for example, is quite laborious. If you take a look at my patch (https://issues.apache.org/bugzilla/show_bug.cgi?id=50483), I've added JUnit tests for quite a few of the classes in the fonts package so that might help you get started. Time wise, most of it is going to be testing since if someone was to implement support for any font features, I'd very strongly suggest JUnit testing as a starting point. The reason being that fonts are quite complicated and introducing bugs is both easy to do and difficult to root out by simply looking at the final PDF/Postscript file. The next issue is having a testbed in order to test regression and ensure that changing a method doesn't break some feature for another font format. This may sound simple, but that means creating the FOs with foreign glyphs, CJK for example, is quite laborious. If you take a look at my patch (https://issues.apache.org/bugzilla/show_bug.cgi?id=50483), I've added JUnit tests for quite a few of the classes in the fonts package so that might help you get started. If you do start implementing this feature, don't hesitate to get in contact and I can try and share some of my knowledge and/or test-suite as an when you require it. Sorry for the verbosity of the email, as you'll find, fonts are not to be underestimated. Mehdi On 18 January 2011 23:11, Glenn Adams
Re: How much work is needed for FOP to support OpenType fonts?
On 18/01/2011 23:11, Glenn Adams wrote: Hi Glenn/Ivan, Most of the Open type Fonts I come across seem to have CFF glyph data which FOP cannot currently support. We find this limitation very annoying and have looked into developing this feature. We haven't started the work though, but did estimate it to be a few weeks work. Thanks, Chris That is a better question, but one I cannot answer, as I have not looked into the CFF support issue. Perhaps another DEV would care to respond. G. On Tue, Jan 18, 2011 at 4:03 PM, Ivan Ristic ivan.ris...@gmail.com mailto:ivan.ris...@gmail.com wrote: On Tue, Jan 18, 2011 at 10:51 PM, Glenn Adams gl...@skynav.com mailto:gl...@skynav.com wrote: Ivan, This type of question is best put to the FOP User fop-us...@xmlgraphics.apache.org mailto:fop-us...@xmlgraphics.apache.org email list rather than the developer list. Actually, I was offering (or considering) to give back some of the money FOP saved me (when I self-published my book). I don't think sending my offer to the users' list would be very useful. In any case, nothing is required of FOP for you to be able to make use of Garamond Pro and other Adobe fonts, though certain advanced typographic features may not be supported. However, if you are not familiar with those advanced features, then that will likely not affect you. For typical western writing systems, you should have no problem with existing off the shelf Truetype and Opentype fonts. Hoping you'd be right, I tried to use Adobe Garamond Pro right now and FOP 1.0 responded to me with OpenType fonts with CFF data are not supported [...]. That leads me to believe that they are indeed not supported. A search on Google did not yield anything useful. If, on the other hand, you are saying that my problem can be resolved on the users' mailing list, I will be happy to give it a try. Or maybe I should instead ask, how much work is to support OpenType fonts with CFF data? Regards, Glenn On Tue, Jan 18, 2011 at 3:41 PM, Ivan Ristic ivan.ris...@gmail.com mailto:ivan.ris...@gmail.com wrote: Glenn, Thanks for your quick response. I don't know what those things mean, so I am afraid I can't be more specific. I was talking purely from a end-user perspective, say, being able to purchase Garamond Pro from Adobe and plug it in with no trouble. [BTW, I appreciate the re-send, but I have subscribed to the list and will stay subscribed for the duration of this email thread.] On Tue, Jan 18, 2011 at 9:27 PM, Glenn Adams gl...@skynav.com mailto:gl...@skynav.com wrote: What do you mean by fully? If you are referring to the OpenType GDEF, GSUB, GPOS support, then work is already underway to add that functionality. See the following for further info: http://people.apache.org/~spepping/ http://people.apache.org/%7Espepping/ http://wiki.apache.org/xmlgraphics-fop/ComplexScripts Regards, Glenn On Tue, Jan 18, 2011 at 2:08 PM, Ivan Ristic ivan.ris...@gmail.com mailto:ivan.ris...@gmail.com wrote: Hi FOP developers, Could someone in the know possibly give me an estimate about how much work is needed to get FOP to fully support OpenType fonts? I understand that estimates can be tough to work out (and that are often unreliable), but even having an idea about the needed amount would help me a great deal. If someone came along to sponsor (fund) such development, would that be acceptable to the group? Thanks. -- Ivan Ristić -- Ivan Ristić -- Ivan Ristić
[VOTE] Merge FOP color branch into trunk
I've cleaned up the color branch, tweaked a few things and did some more testing. I'm happy with the current state, so I'm calling for a vote to merge the current FOP color branch into trunk. https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color +1 from me, obviously. Jeremias Maerki
Re: OpenType font library [was: Re: How much work is needed for FOP to support OpenType fonts?]
On 19/01/11 16:35, Simon Pepping wrote: I take this discussion to express my worries that FOP needs to create its own support for fonts, among which Open Type Fonts. FOP's core task is the layout and printing of FO files. If FOP could rely on good font libraries, that would make our code base so much smaller and our development tasks so much easier. If I am not mistaken, Firefox does a fairly good job at representing Indic scripts. Do they use a generally available library? There are several libraries for complex scripts, including the commonly-used libbidi and pango libraries. All the widely used ones that I know of are C- or C++ libraries. While Java can use C and C++ libraries, a Java Native Interface (JNI) layer must be written. Further, JNI code and the libraries it uses must be compiled separately for each supported platform and architecture, making packaging and deployment of the Java code a ***PAIN*** unless all the native code parts are shipped as part of the JDK/JRE. Even allowing for the issues with complex/bidi libraries, Apache FOP must also handle the OpenType font format its self, including support for font subsetting and embedding. That's way outside the scope of complex script and bidi libraries. While library code exists to help with OpenType handling, I'm not aware of any even C or C++ libraries that provide useful, fairly abstracted facilities for subsetting and embedding without tying them in to related PDF libraries. While Java its self can use OpenType fonts, it doesn't expose the details of its OpenType parser etc to Java applications. In any case, it may use the platform's font support rather than bundling its own. Java apps need to provide their own OpenType format handling if they want to do more than just use the fonts with Graphics2D and the other Java rendering APIs, because there's no way to get to the guts of the fonts loaded by the JVM. Ideally, Apache FOP could be built on top of: - A low-level Java font format and parsing library that can identify fonts, enumerate tables and glyphs, detect features, etc. - A low-level Java PDF library that handles the PDF document structure, xref and indirect object management, PDF data structure representation, direct-to-disk streaming of big images into PDF object streams, etc etc. - A Java library that uses both of the above to provide features for PDF embedding of OpenType and TrueType fonts. Unfortunately, AFAIK *NONE* of them exist, or at least are used, at present. Fop seems to have its own PDF output code and own font handling code. I don't see any obviously advantagous 3rd party replacements for the font handling code, and most of the 3rd party PDF engines (like iText) appear to be a bit limited when you want to insert your own low-level PDF content stream data, objects, etc to implement features not supported directly by the PDF library you're using. I was looking into this a little myself while checking to see how hard it'd be to implement /DeviceCMYK and /ICCBased colour in FOP. Because of the way FOP stores and manages colour internally, the answer appears to be very at present, especially if you want to support PDF/X requirements and handle CMYK passthrough. -- System Network Administrator POST Newspapers
Re: OpenType font library [was: Re: How much work is needed for FOP to support OpenType fonts?]
I agree, native libraries would be a pain. BTW, interested parties could take a look at Apache FontBox's CFF support. That's part of Apache PDFBox. Maybe that could be used or adapted. On 19.01.2011 11:59:18 Craig Ringer wrote: On 19/01/11 16:35, Simon Pepping wrote: I take this discussion to express my worries that FOP needs to create its own support for fonts, among which Open Type Fonts. FOP's core task is the layout and printing of FO files. If FOP could rely on good font libraries, that would make our code base so much smaller and our development tasks so much easier. If I am not mistaken, Firefox does a fairly good job at representing Indic scripts. Do they use a generally available library? There are several libraries for complex scripts, including the commonly-used libbidi and pango libraries. All the widely used ones that I know of are C- or C++ libraries. While Java can use C and C++ libraries, a Java Native Interface (JNI) layer must be written. Further, JNI code and the libraries it uses must be compiled separately for each supported platform and architecture, making packaging and deployment of the Java code a ***PAIN*** unless all the native code parts are shipped as part of the JDK/JRE. Even allowing for the issues with complex/bidi libraries, Apache FOP must also handle the OpenType font format its self, including support for font subsetting and embedding. That's way outside the scope of complex script and bidi libraries. While library code exists to help with OpenType handling, I'm not aware of any even C or C++ libraries that provide useful, fairly abstracted facilities for subsetting and embedding without tying them in to related PDF libraries. While Java its self can use OpenType fonts, it doesn't expose the details of its OpenType parser etc to Java applications. In any case, it may use the platform's font support rather than bundling its own. Java apps need to provide their own OpenType format handling if they want to do more than just use the fonts with Graphics2D and the other Java rendering APIs, because there's no way to get to the guts of the fonts loaded by the JVM. Ideally, Apache FOP could be built on top of: - A low-level Java font format and parsing library that can identify fonts, enumerate tables and glyphs, detect features, etc. - A low-level Java PDF library that handles the PDF document structure, xref and indirect object management, PDF data structure representation, direct-to-disk streaming of big images into PDF object streams, etc etc. - A Java library that uses both of the above to provide features for PDF embedding of OpenType and TrueType fonts. Unfortunately, AFAIK *NONE* of them exist, or at least are used, at present. Fop seems to have its own PDF output code and own font handling code. I don't see any obviously advantagous 3rd party replacements for the font handling code, and most of the 3rd party PDF engines (like iText) appear to be a bit limited when you want to insert your own low-level PDF content stream data, objects, etc to implement features not supported directly by the PDF library you're using. I was looking into this a little myself while checking to see how hard it'd be to implement /DeviceCMYK and /ICCBased colour in FOP. Because of the way FOP stores and manages colour internally, the answer appears to be very at present, especially if you want to support PDF/X requirements and handle CMYK passthrough. -- System Network Administrator POST Newspapers Jeremias Maerki
Re: color issues [was: OpenType font library]
Craig, you might want to try out the color branches for which I've just started to vote to merge it into trunk. The color branch adds Named Color (separation, spot color) support and CIE Lab support. However, ICC and device CMYK colors should already work in FOP Trunk/1.0. Could you maybe elaborate on your problems there? On 19.01.2011 11:59:18 Craig Ringer wrote: snip/ I was looking into this a little myself while checking to see how hard it'd be to implement /DeviceCMYK and /ICCBased colour in FOP. Because of the way FOP stores and manages colour internally, the answer appears to be very at present, especially if you want to support PDF/X requirements and handle CMYK passthrough. -- System Network Administrator POST Newspapers Jeremias Maerki
Re: color issues [was: OpenType font library]
On 19/01/11 19:13, Jeremias Maerki wrote: Craig, you might want to try out the color branches for which I've just started to vote to merge it into trunk. The color branch adds Named Color (separation, spot color) support and CIE Lab support. However, ICC and device CMYK colors should already work in FOP Trunk/1.0. Could you maybe elaborate on your problems there? Hmm. I seem to have missed the cmyk() function in fop, and less excusably the rgb-icc() function in XSL-FO proper. Maybe it was CMYK and ICC tagged images I was having issues with? I'll look into it again, it's been ages since I was looking at that, and I was on fop 0.95 when investigating that stuff so it may have changed since then anyway. -- System Network Administrator POST Newspapers
Re: OpenType font library [was: Re: How much work is needed for FOP to support OpenType fonts?]
I think we are taking the only reasonable route available w.r.t. complex script support, namely reading the OTF font directly to extract and use the advanced typographic tables. The same mechanisms can be used for the TTF AAT tables as well. The inquiry that started this thread seems most interested in CFF support, and not complex scripts. However, I haven't looked into what is needed to add CFF support. G. On Wed, Jan 19, 2011 at 4:10 AM, Jeremias Maerki d...@jeremias-maerki.chwrote: I agree, native libraries would be a pain. BTW, interested parties could take a look at Apache FontBox's CFF support. That's part of Apache PDFBox. Maybe that could be used or adapted. On 19.01.2011 11:59:18 Craig Ringer wrote: On 19/01/11 16:35, Simon Pepping wrote: I take this discussion to express my worries that FOP needs to create its own support for fonts, among which Open Type Fonts. FOP's core task is the layout and printing of FO files. If FOP could rely on good font libraries, that would make our code base so much smaller and our development tasks so much easier. If I am not mistaken, Firefox does a fairly good job at representing Indic scripts. Do they use a generally available library? There are several libraries for complex scripts, including the commonly-used libbidi and pango libraries. All the widely used ones that I know of are C- or C++ libraries. While Java can use C and C++ libraries, a Java Native Interface (JNI) layer must be written. Further, JNI code and the libraries it uses must be compiled separately for each supported platform and architecture, making packaging and deployment of the Java code a ***PAIN*** unless all the native code parts are shipped as part of the JDK/JRE. Even allowing for the issues with complex/bidi libraries, Apache FOP must also handle the OpenType font format its self, including support for font subsetting and embedding. That's way outside the scope of complex script and bidi libraries. While library code exists to help with OpenType handling, I'm not aware of any even C or C++ libraries that provide useful, fairly abstracted facilities for subsetting and embedding without tying them in to related PDF libraries. While Java its self can use OpenType fonts, it doesn't expose the details of its OpenType parser etc to Java applications. In any case, it may use the platform's font support rather than bundling its own. Java apps need to provide their own OpenType format handling if they want to do more than just use the fonts with Graphics2D and the other Java rendering APIs, because there's no way to get to the guts of the fonts loaded by the JVM. Ideally, Apache FOP could be built on top of: - A low-level Java font format and parsing library that can identify fonts, enumerate tables and glyphs, detect features, etc. - A low-level Java PDF library that handles the PDF document structure, xref and indirect object management, PDF data structure representation, direct-to-disk streaming of big images into PDF object streams, etc etc. - A Java library that uses both of the above to provide features for PDF embedding of OpenType and TrueType fonts. Unfortunately, AFAIK *NONE* of them exist, or at least are used, at present. Fop seems to have its own PDF output code and own font handling code. I don't see any obviously advantagous 3rd party replacements for the font handling code, and most of the 3rd party PDF engines (like iText) appear to be a bit limited when you want to insert your own low-level PDF content stream data, objects, etc to implement features not supported directly by the PDF library you're using. I was looking into this a little myself while checking to see how hard it'd be to implement /DeviceCMYK and /ICCBased colour in FOP. Because of the way FOP stores and manages colour internally, the answer appears to be very at present, especially if you want to support PDF/X requirements and handle CMYK passthrough. -- System Network Administrator POST Newspapers Jeremias Maerki
DO NOT REPLY [Bug 50483] [PATCH] Full font embedding and Subset embedding in Post Script
https://issues.apache.org/bugzilla/show_bug.cgi?id=50483 Mehdi Houshmand med1...@gmail.com changed: What|Removed |Added Attachment #26504|0 |1 is obsolete|| --- Comment #7 from Mehdi Houshmand med1...@gmail.com 2011-01-19 11:11:04 EST --- Created an attachment (id=26517) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26517) More improvements Bug Fixed - ConcurrentModificationException -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
zero checkstyle/findbugs warnings!!
i just fast forwarded 31 checkins into my copy of trunk and built, tested, checked styles and ran findbugs, and ZERO style errors or findbugs warnings are reported!! i'm very happy to see that we are now paying attention to code quality testing in a real way, so congratulations dev team! best regards, glenn
