Re: OpenType font library [was: Re: How much work is needed for FOP to support OpenType fonts?]

[Glenn Adams]

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 wrote:

> 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: How much work is needed for FOP to support OpenType fonts?

[Eric Douglas]

Did you read what I wrote?  The simple answer is don't use postscript.  Is 
there a particular reason you must use the postscript format?
I tried getting the output in postscript format and it didn't turn out well.  I 
believe they said to use that format you should only use type 1 fonts.
If you get the document as a byte stream you can pass it into the pdfbox 
program which builds a Pageable pdf document still in memory.  No physical 
files are required with this method.  You can pass the pdfbox PDDocument to a 
Java PrinterJob and just print it.
I embed one standard font, which is up to 3 fonts (one for normal, one for 
bold, one for some unicode characters).  I chose Lucida Typewriter for 
everything because it is the most readable fixed width font.
 

-Original Message-
From: mehdi houshmand [mailto:med1...@gmail.com] 
Sent: Wednesday, January 19, 2011 9:29 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: How much work is needed for FOP to support OpenType fonts?

Hi Eric,

I'm afraid it's not that simple, PostScript doens't accept a byte stream as PDF 
does. In order to embed fonts into a PostScript document, the font must be 
streamed to an ASCII hexadecimal stream. As you can imagine, this bloats the 
size quite significantly, and imagine if you have several fonts, all fully 
embedded. One of my test documents was 100+ MB, that's clearly unacceptable and 
crashes a two of the 3 printers I use for testing. This isn't as much of an 
issue in PDF since you can stream bytes directly to the document.

Mehdi

On 19 January 2011 14:22, Eric Douglas  wrote:
> I'd like to know what sort of document you're trying to print and what 
> sort of printer you're using if it won't accept a truetype font.
> I only print truetype fonts (lucida typewriter) with FOP and I have no 
> problems printing to brand new lasers or dot matrix which are at least 
> 10 years old.
> I don't know how much document size might affect that or if you could 
> do some special processing to handle large documents.
> Our typical printout from that program going to the old dot matrix 
> printer is 2-3 pages and a large printout might be 5-10 pages.
> I haven't had any size issues with embedding the full font since the 
> typical 2 page printout is about a 60kb pdf.  That's including an 
> embedded svg image on every page.
>
> If your printouts don't work maybe you could try printing differently.
> I print using embedded code.  I create a new Fop object using a new 
> ByteArrayOutputStream, then create a new SAXResult from that Fop's 
> DefaultHandler.  Then I pass the SAXResult into a transform which puts 
> the document into that ByteArrayOutputStream.  Then I get the document 
> from the stream with it's toByteArray and pass those bytes into a 
> ByteArrayInputStream which I can load into a pdfbox object, which is a 
> Pageable object I just pass to the Java print method and it just works 
> on any printer.  It has the old dot matrix printers printing graphics 
> and variable font sizes I didn't know they were capable of.
>
>
> -----Original Message-----
> From: mehdi houshmand [mailto:med1...@gmail.com]
> Sent: Wednesday, January 19, 2011 5:06 AM
> To: fop-dev@xmlgraphics.apache.org
> Subject: 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
>

Re: How much work is needed for FOP to support OpenType fonts?

[mehdi houshmand]

Hi Eric,

I'm afraid it's not that simple, PostScript doens't accept a byte
stream as PDF does. In order to embed fonts into a PostScript
document, the font must be streamed to an ASCII hexadecimal stream. As
you can imagine, this bloats the size quite significantly, and imagine
if you have several fonts, all fully embedded. One of my test
documents was 100+ MB, that's clearly unacceptable and crashes a two
of the 3 printers I use for testing. This isn't as much of an issue in
PDF since you can stream bytes directly to the document.

Mehdi

On 19 January 2011 14:22, Eric Douglas  wrote:
> I'd like to know what sort of document you're trying to print and what
> sort of printer you're using if it won't accept a truetype font.
> I only print truetype fonts (lucida typewriter) with FOP and I have no
> problems printing to brand new lasers or dot matrix which are at least
> 10 years old.
> I don't know how much document size might affect that or if you could do
> some special processing to handle large documents.
> Our typical printout from that program going to the old dot matrix
> printer is 2-3 pages and a large printout might be 5-10 pages.
> I haven't had any size issues with embedding the full font since the
> typical 2 page printout is about a 60kb pdf.  That's including an
> embedded svg image on every page.
>
> If your printouts don't work maybe you could try printing differently.
> I print using embedded code.  I create a new Fop object using a new
> ByteArrayOutputStream, then create a new SAXResult from that Fop's
> DefaultHandler.  Then I pass the SAXResult into a transform which puts
> the document into that ByteArrayOutputStream.  Then I get the document
> from the stream with it's toByteArray and pass those bytes into a
> ByteArrayInputStream which I can load into a pdfbox object, which is a
> Pageable object I just pass to the Java print method and it just works
> on any printer.  It has the old dot matrix printers printing graphics
> and variable font sizes I didn't know they were capable of.
>
>
> -Original Message-----
> From: mehdi houshmand [mailto:med1...@gmail.com]
> Sent: Wednesday, January 19, 2011 5:06 AM
> To: fop-dev@xmlgraphics.apache.org
> Subject: 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
>

RE: How much work is needed for FOP to support OpenType fonts?

[Eric Douglas]

I'd like to know what sort of document you're trying to print and what
sort of printer you're using if it won't accept a truetype font.
I only print truetype fonts (lucida typewriter) with FOP and I have no
problems printing to brand new lasers or dot matrix which are at least
10 years old.
I don't know how much document size might affect that or if you could do
some special processing to handle large documents.
Our typical printout from that program going to the old dot matrix
printer is 2-3 pages and a large printout might be 5-10 pages.
I haven't had any size issues with embedding the full font since the
typical 2 page printout is about a 60kb pdf.  That's including an
embedded svg image on every page.

If your printouts don't work maybe you could try printing differently.
I print using embedded code.  I create a new Fop object using a new
ByteArrayOutputStream, then create a new SAXResult from that Fop's
DefaultHandler.  Then I pass the SAXResult into a transform which puts
the document into that ByteArrayOutputStream.  Then I get the document
from the stream with it's toByteArray and pass those bytes into a
ByteArrayInputStream which I can load into a pdfbox object, which is a
Pageable object I just pass to the Java print method and it just works
on any printer.  It has the old dot matrix printers printing graphics
and variable font sizes I didn't know they were capable of.
 

-Original Message-
From: mehdi houshmand [mailto:med1...@gmail.com] 
Sent: Wednesday, January 19, 2011 5:06 AM
To: fop-dev@xmlgraphics.apache.org
Subject: 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

Re: OpenType font library [was: Re: How much work is needed for FOP to support OpenType fonts?]

[Jeremias Maerki]

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: How much work is needed for FOP to support OpenType fonts?

[Craig Ringer]

On 19/01/11 18:38, Chris Bowditch wrote:
> 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.

I'm facing similar issues. I'm most of the way through implementing a
simple classified advertising pagination system that uses Apache FOP as
its output backend - and I'll initially be restricted to TrueType fonts.
Given that the company uses almost exclusively OpenType fonts, that's
kinda frustrating. On the other hand, I'm happy to have something as
useful as FOP to work with, as otherwise I'd be trying to massage TeX to
do what I want and losing a lot of hair in the process.

(The other thing that's biting me is lack of /ICCBased and /DeviceCMYK
PDF colour support in FOP - but in my workflow that's not a big issue as
I can convert the FOP-produced PDFs during preflight).

-- 
System & Network Administrator
POST Newspapers

Re: OpenType font library [was: Re: How much work is needed for FOP to support OpenType fonts?]

[Craig Ringer]

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: How much work is needed for FOP to support OpenType fonts?

[Chris Bowditch]

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 > wrote:


On Tue, Jan 18, 2011 at 10:51 PM, Glenn Adams mailto:gl...@skynav.com>> wrote:
> Ivan,
> This type of question is best put to the FOP User
> 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
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 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://wiki.apache.org/xmlgraphics-fop/ComplexScripts
>> > Regards,
>> > Glenn
>> >
>> > On Tue, Jan 18, 2011 at 2:08 PM, Ivan Ristic
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ć

Re: How much work is needed for FOP to support OpenType fonts?

[mehdi houshmand]

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  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 verbo

Re: How much work is needed for FOP to support OpenType fonts?

[Jeremias Maerki]

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  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  wrote:
> >>
> >> On Tue, Jan 18, 2011 at 10:51 PM, Glenn Adams  wrote:
> >> > Ivan,
> >> > This type of question is best put to the FOP User
> >> >  email list rather than the developer
> >> > list.
> >>

Re: OpenType font library [was: Re: How much work is needed for FOP to support OpenType fonts?]

[mehdi houshmand]

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  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  wrote:
>>
>> > On Tue, Jan 18, 2011 at 10:51 PM, Glenn Adams  wrote:
>> > >
>> > > On Tue, Jan 18, 2011 at 3:41 PM, Ivan Ristic 
>> > wrote:
>> > >>
>> > >> On Tue, Jan 18, 2011 at 9:27 PM, Glenn Adams  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 houshmand]

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  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  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  wrote:
>>>
>>> On Tue, Jan 18, 2011 at 10:51 PM, Glenn Adams  wrote:
>>> > Ivan,
>>> > This type of question is best put to the FOP User
>>> >  em

Re: How much work is needed for FOP to support OpenType fonts?

[mehdi houshmand]

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  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  wrote:
>>
>> On Tue, Jan 18, 2011 at 10:51 PM, Glenn Adams  wrote:
>> > Ivan,
>> > This type of question is best put to the FOP User
>> >  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

OpenType font library [was: Re: How much work is needed for FOP to support OpenType fonts?]

[Simon Pepping]

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  wrote:
> 
> > On Tue, Jan 18, 2011 at 10:51 PM, Glenn Adams  wrote:
> > >
> > > On Tue, Jan 18, 2011 at 3:41 PM, Ivan Ristic 
> > wrote:
> > >>
> > >> On Tue, Jan 18, 2011 at 9:27 PM, Glenn Adams  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?

[Glenn Adams]

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  wrote:

> On Tue, Jan 18, 2011 at 10:51 PM, Glenn Adams  wrote:
> > Ivan,
> > This type of question is best put to the FOP User
> >  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 
> 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  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 
> >> > 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ć
>

Re: How much work is needed for FOP to support OpenType fonts?

[Ivan Ristic]

On Tue, Jan 18, 2011 at 10:51 PM, Glenn Adams  wrote:
> Ivan,
> This type of question is best put to the FOP User
>  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  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  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 
>> > 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ć

Re: How much work is needed for FOP to support OpenType fonts?

[Glenn Adams]

Ivan,

This type of question is best put to the FOP User <
fop-us...@xmlgraphics.apache.org> email list rather than the developer list.
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.

Regards,
Glenn

On Tue, Jan 18, 2011 at 3:41 PM, Ivan Ristic  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  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 
> 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ć
>

Re: How much work is needed for FOP to support OpenType fonts?

[Ivan Ristic]

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  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  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ć

Re: How much work is needed for FOP to support OpenType fonts?

[Glenn Adams]

Resending to original sender.

On Tue, Jan 18, 2011 at 2:27 PM, Glenn Adams  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 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ć
>>
>
>

Re: How much work is needed for FOP to support OpenType fonts?

[Glenn Adams]

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  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ć
>