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 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> >>> > 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> 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 >>> >> > Regards, >>> >> > Glenn >>> >> > >>> >> > On Tue, Jan 18, 2011 at 2:08 PM, Ivan Ristic <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ć >> >> >