RE: PSDocumentGraphics2D and Font dictionary
Jeremias Maerki wrote: BTW, are these fonts well defined in the postscript standard? Or do they only exist in PDF? PDF was derived from PostScript, so yes, they are well-defined. There is a group of so-called Base-35 fonts for PostScript that is a superset of the Base-14 fonts. I was always under the impression that PostScript implementations were required to support them just as PDF Renderers are required to support the Base-14. However, I am currently under the impression that the Base-35 is more of a convention than a standard, so it may not be quite as well-defined, but it is probably reasonable to assume that they are there. If the current approach is very difficult to implement, then I think it's best to use the approach with the renderer hint. IIUC, the current approach is to define all fonts that are registered and to embed all that are not Base-14. That is not too difficult to implement, but I think Vincent's point was that it seemed wrong. It would not be too hard to add a method that provides a collection of all registered fonts, but the Font objects returned must actually be parsed, which could be a lot of wasted overhead. The question would be whether that should be a standard aXSL method or whether it should be viewed as a hack that would just require an extension to FOrayFontServer. Since I gather that FOP will not be supporting the reuse of a FontServer instance (i.e. each document will have its own instance of FontServer), perhaps it works fine to just have the user provide a separate font-configuration file that contains only the fonts needed for the document. I can implement that for you if you want. Only referring to the font name will not work since we currently have to reencode each font to the WinAnsi charset. And since each PostScript page should be self-sufficient and removable, we can't do this reencoding when the font appears for the first time. Actually, you are no longer tied to WinAnsi. We have a lot more flexibility on encodings than before: 1. All of the predefined encodings for both PostScript and PDF are available to either platform -- of course, if they are not predefined for the platform used, they must be written into the output. 2. Both platforms have access to the font's internal encoding. 3. The user can specify custom encodings through the font-configuration file. So, if a PostScript document can use the font's internal encoding, and if the font is known to already be available to the interpreter, I think it could safely be used by name. But perhaps I have forgotten something. This may require a new font-configuration item for the font element that allows it to tell whether it is known to be available to the PostScript interpreter. There are some other possibilities here as well. Anyway, there are some more options for you to consider. Victor Mote
Re: PSDocumentGraphics2D and Font dictionary
On 13.09.2005 15:47:12 Victor Mote wrote: Jeremias Maerki wrote: BTW, are these fonts well defined in the postscript standard? Or do they only exist in PDF? PDF was derived from PostScript, so yes, they are well-defined. There is a group of so-called Base-35 fonts for PostScript that is a superset of the Base-14 fonts. I was always under the impression that PostScript implementations were required to support them just as PDF Renderers are required to support the Base-14. However, I am currently under the impression that the Base-35 is more of a convention than a standard, so it may not be quite as well-defined, but it is probably reasonable to assume that they are there. I just found this: Appendix E of the PS bible, uhm, PostScript Language Reference (third edition) says: While there is not a standard set of fonts that is required by the PostScript language, most PostScript products include software for 13 standard fonts from the Times, Helvetica, Courier and Symbol families. Looks like you can't even be 100% sure that the base 14 fonts are available. If the current approach is very difficult to implement, then I think it's best to use the approach with the renderer hint. IIUC, the current approach is to define all fonts that are registered and to embed all that are not Base-14. That is not too difficult to implement, but I think Vincent's point was that it seemed wrong. It would not be too hard to add a method that provides a collection of all registered fonts, but the Font objects returned must actually be parsed, which could be a lot of wasted overhead. The question would be whether that should be a standard aXSL method or whether it should be viewed as a hack that would just require an extension to FOrayFontServer. Let's look at it from another side. If someone writes some kind of FO editor or a configuration tool for FOray/FOP a method that reports all available fonts will certainly be useful. :-) Since I gather that FOP will not be supporting the reuse of a FontServer instance (i.e. each document will have its own instance of FontServer), perhaps it works fine to just have the user provide a separate font-configuration file that contains only the fonts needed for the document. No, I think there will definitely come a point in time where I will want some kind of object holding on to global font configuration but which is not a static mechanism. Although it's possible to reuse the FOUserAgent, the user agent IMO is something that is bound to a rendering run. We simply haven't finalized the API, yet, or I'm at least not ready to call it finalized. :-) I can implement that for you if you want. Only referring to the font name will not work since we currently have to reencode each font to the WinAnsi charset. And since each PostScript page should be self-sufficient and removable, we can't do this reencoding when the font appears for the first time. Actually, you are no longer tied to WinAnsi. We have a lot more flexibility on encodings than before: 1. All of the predefined encodings for both PostScript and PDF are available to either platform -- of course, if they are not predefined for the platform used, they must be written into the output. 2. Both platforms have access to the font's internal encoding. 3. The user can specify custom encodings through the font-configuration file. So, if a PostScript document can use the font's internal encoding, and if the font is known to already be available to the interpreter, I think it could safely be used by name. But perhaps I have forgotten something. No, that's true. I simply haven't cared, yet, about finding out how glyphs are accessed on-the-fly in PS that are not accessible through the encoding. Rewriting the encoding seemed easier. This may require a new font-configuration item for the font element that allows it to tell whether it is known to be available to the PostScript interpreter. There are some other possibilities here as well. I bet. Sounds good. Anyway, there are some more options for you to consider. We're surely not going to run out of discussion topics and things to do. :-) Thanks for your input. Jeremias Maerki
Re: PSDocumentGraphics2D and Font dictionary
Let's look at it from another side. If someone writes some kind of FO editor or a configuration tool for FOray/FOP a method that reports all available fonts will certainly be useful. :-) OK. That makes sense. To avoid wasteful parsing, it will mean that at least 3 new classes need to be exposed through interfaces (RegisteredFont, RegisteredFontFamily, and RegisteredFontDesc), which may be a good thing anyway. Yes, I think it could be interesting. It would also be necessary to add getStream methods, now that font parsing is delegated to the font server. Currently there is only one getPDFFontFileStream method. There should perhaps be also a getPSFontFileStream, and something like getPDF/PSSubset? It seems that the client is unable to make font subsetting with the current interface. RegisteredFontFamily and RegisteredFontDesc might also be interesting for the AWT renderer, but that's another purpose. I'll perhaps come back on this later. (more below) Very good. It sounds like you and I may end up with API visions that match better than I might have thought at one time. Actually, you are no longer tied to WinAnsi. We have a lot more flexibility on encodings than before: 1. All of the predefined encodings for both PostScript and PDF are available to either platform -- of course, if they are not predefined for the platform used, they must be written into the output. 2. Both platforms have access to the font's internal encoding. 3. The user can specify custom encodings through the font-configuration file. So, if a PostScript document can use the font's internal encoding, and if the font is known to already be available to the interpreter, I think it could safely be used by name. But perhaps I have forgotten something. No, that's true. I simply haven't cared, yet, about finding out how glyphs are accessed on-the-fly in PS that are not accessible through the encoding. Rewriting the encoding seemed easier. I am very sure that for Type 1 fonts, specifying another encoding is the only way to get it done. There is just no way to get more than 256 combinations out of 8 bits and there is no way to get more than 8 bits. However, the good news is that I am 99% sure that for both PDF and PostScript you can specify the same underlying font with two (or more) different encodings. They will actually show up as two different font objects in the document and must of course be referred to that way also. I'll let you know how that turns out. This may require a new font-configuration item for the font element that allows it to tell whether it is known to be available to the PostScript interpreter. There are some other possibilities here as well. I bet. Sounds good. The more I think about it, encapsulating the characteristics of a specific PostScript interpreter is probably the right way to go. Then the rendering run can use that to decide whether the font needs to be embedded or not. I'll have to ponder that for awhile. Here I'm beginning to get lost because I don't know the Postscript standard. My hope to get ready before the upcoming realease starts vanishing... :-( Here's my summary of the current discussion: 1. Currently the Fop PSRenderer embeds all of the configured fonts in the PS file, even those that will never be used. It does this by parsing itself the font files; 2. I can't reproduce this behavior with aXSL and FOray easily, because I've no direct access to the font files; 3. Still doing this would require hacking the FOrayFont subpackage; that would result in something dirty but that should work; 4. Anyway there are several improvements to bring to the PS renderer: mainly character encoding, font embedding and in a longer term two-pass rendering for a proper font handling. Now I'm thinking of the next release: simply putting the font name in the postscript file would be rather straightforward to implement, and should work for most of cases (?), thanks to the non-standard but well-known base14 (and even base35) font set. But that's definitely a regression from the current state. Improving the PS renderer to allow proper embedding will require (1) changes to the aXSL interfaces (so a certain amount of discussions), (2) me to learn Postscript. That would prevent the FOrayFont subsystem from being integrated in the pre-release. Do you agree with my summary? Integrating FOrayFont in the pre-release would be great... Deciding to delay the integration would give me more time to investigate the insides of FOrayFont, learn PS and PDF standards and so do things much better. If there is a decision to make it does not belong to me... Vincent
RE: PSDocumentGraphics2D and Font dictionary
Vincent Hennebert wrote:
OK. That makes sense. To avoid wasteful parsing, it will
mean that at
least
3 new classes need to be exposed through interfaces
(RegisteredFont,
RegisteredFontFamily, and RegisteredFontDesc), which may be a good
thing anyway.
Yes, I think it could be interesting. It would also be
necessary to add getStream methods, now that font parsing is
delegated to the font server.
Currently there is only one getPDFFontFileStream method.
There should perhaps be also a getPSFontFileStream, and
something like getPDF/PSSubset? It seems that the client is
unable to make font subsetting with the current interface.
OK. I have actually not been sure how much of the code is reusable between
the two. PS rendering is way lower on my priority list than PDF, so I don't
work with it much. Here is our decision tree:
if (PS font embedding works in FOP now) {
if (it been added since May, 2004, when I forked the FOP code) {
we need to patch FOray with that logic;
} else {
Victor somehow lost this in the refactoring work;
FOray still needs to be patched;
}
} else {
we can add PS font embedding later;
}
I am not sure what you mean getPDF/PSSubset.
The more I think about it, encapsulating the
characteristics of a specific
PostScript interpreter is probably the right way to go.
Then the rendering
run can use that to decide whether the font needs to be
embedded or not.
I'll have to ponder that for awhile.
Here I'm beginning to get lost because I don't know the
Postscript standard.
My hope to get ready before the upcoming realease starts
vanishing... :-(
Here's my summary of the current discussion:
1. Currently the Fop PSRenderer embeds all of the configured
fonts in the PS
file, even those that will never be used. It does this by
parsing itself the
font files;
Hmmm. I think something has changed here since I last looked at it.
Jeremias?
2. I can't reproduce this behavior with aXSL and FOray
easily, because I've no
direct access to the font files;
Point me to the FOP code that does the embedding, class name(s) and line
numbers, and I'll see if I can extract it into an aXSL-exposed method.
3. Still doing this would require hacking the FOrayFont
subpackage; that would
result in something dirty but that should work;
Better would be to just make aXSL provide what needs to be provided. If we
can hack FOray to do it, then we should be able to expose what is needed.
Since nothing we are talking about here is a pollution of the interface, we
should just be able to change the interface.
4. Anyway there are several improvements to bring to the PS
renderer: mainly
character encoding, font embedding and in a longer term
two-pass rendering for a
proper font handling.
OK. I am confused. I thought above that font embedding worked in PS now, but
this seems to indicate that it does not.
Now I'm thinking of the next release: simply putting the font
name in the
postscript file would be rather straightforward to implement,
and should work
for most of cases (?), thanks to the non-standard but
well-known base14 (and
even base35) font set. But that's definitely a regression
from the current state.
Improving the PS renderer to allow proper embedding will
require (1) changes to
the aXSL interfaces (so a certain amount of discussions),
(2) me to learn
Postscript. That would prevent the FOrayFont subsystem from
being integrated in
the pre-release.
Do you agree with my summary?
I can take some of this burden off of you, in that I can hopefully fix aXSL
and FOray to provide what is needed. If that is done well, you shouldn't
need to learn too much PostScript to get it to work, and perhaps one of the
other developers can help you get it glued in. I don't know how much work it
will take for me to get the FOray PS Renderer working (it may work now), I
can use that as a test bed also.
Even if we can't get PS embedding working in time for the release (and I
think we should be able to), I am not sure whether this is a step backwards
from 0.20.5. I can't imagine that I just totally yanked PS embedding code
out of the FOray PS renderer.
Integrating FOrayFont in the pre-release would be great...
Deciding to delay the integration would give me more time to
investigate the
insides of FOrayFont, learn PS and PDF standards and so do
things much better.
If there is a decision to make it does not belong to me...
Vincent
Nor to me. I'll just try to help get working what you need and let you guys
decide what works best.
Victor Mote
Re: PSDocumentGraphics2D and Font dictionary
On 13.09.2005 20:57:31 Vincent Hennebert wrote: Let's look at it from another side. If someone writes some kind of FO editor or a configuration tool for FOray/FOP a method that reports all available fonts will certainly be useful. :-) OK. That makes sense. To avoid wasteful parsing, it will mean that at least 3 new classes need to be exposed through interfaces (RegisteredFont, RegisteredFontFamily, and RegisteredFontDesc), which may be a good thing anyway. Yes, I think it could be interesting. It would also be necessary to add getStream methods, now that font parsing is delegated to the font server. Currently there is only one getPDFFontFileStream method. There should perhaps be also a getPSFontFileStream, and something like getPDF/PSSubset? It seems that the client is unable to make font subsetting with the current interface. And what about PCL? And SVG? And AFP? IMO, output format specific code should not appear in the main interfaces for font access. Every target platform will have their little specialities: special font formats, font conversions may be necessary (Type 1 to SVG fonts, SVG fonts to Type 3). It makes sense to write font embedding code directly in the renderer. The font provider can certainly make the job easier by providing access to often-used data and especially to the raw font streams. But that may be limited to certain aspects of a font type or dependant on the font subsystem implementation. Providing a font to a layout engine has also different requirements than embedding or using a font in a specific output format. Maybe the Font interface should simply have a method to return a very generic interface for more detailed and font- and output-system-specific access to the font. Consumers of this interface can then cast it to a special interface/class. Something like: TargetFormatHelper Font.getTargetFormatHelper(String mime) Subclasses of TargetFormatHelper could be PDFTargetFormatHelper or a PSTargetFormatHelper. The Font interface in aXSL seems to be overloaded already, so this might be an improvement anyway. snip/ The more I think about it, encapsulating the characteristics of a specific PostScript interpreter is probably the right way to go. Then the rendering run can use that to decide whether the font needs to be embedded or not. I'll have to ponder that for awhile. Here I'm beginning to get lost because I don't know the Postscript standard. My hope to get ready before the upcoming realease starts vanishing... :-( It's a complex problem area. I'm not surprised. Here's my summary of the current discussion: 1. Currently the Fop PSRenderer embeds all of the configured fonts in the PS file, even those that will never be used. It does this by parsing itself the font files; 2. I can't reproduce this behavior with aXSL and FOray easily, because I've no direct access to the font files; Which is a problem IMO. See my comments above. 3. Still doing this would require hacking the FOrayFont subpackage; that would result in something dirty but that should work; I believe this can be designed in way that is even cleaner than it is now. I just wish I had time to participate but my priorities make that impossible. 4. Anyway there are several improvements to bring to the PS renderer: mainly character encoding, font embedding and in a longer term two-pass rendering for a proper font handling. Now I'm thinking of the next release: simply putting the font name in the postscript file would be rather straightforward to implement, and should work for most of cases (?), thanks to the non-standard but well-known base14 (and even base35) font set. Without the knowledge on how to access a glyph outside the default encoding, characters like the very important Euro character will be impossible to produce. But that's definitely a regression from the current state. Improving the PS renderer to allow proper embedding will require (1) changes to the aXSL interfaces (so a certain amount of discussions), (2) me to learn Postscript. That would prevent the FOrayFont subsystem from being integrated in the pre-release. If aXSL-font provides access to the raw underlying font streams, that problem basically dissolves. The following would certainly be no problem: InputStream Font.getRawStream(String part) where part may be pfb, pfm, afm, ttf etc. Do you agree with my summary? Integrating FOrayFont in the pre-release would be great... Quite unrealistic as it stands now, sorry. Deciding to delay the integration would give me more time to investigate the insides of FOrayFont, learn PS and PDF standards and so do things much better. If there is a decision to make it does not belong to me... Look, the first preview release doesn't have to be perfect. It's simply a first big sign to the outside world that FOP is not dead but is instead back in business with a much better codebase. That's the sole purpose of
Re: PSDocumentGraphics2D and Font dictionary
On 13.09.2005 21:47:01 Victor Mote wrote: snip/ 1. Currently the Fop PSRenderer embeds all of the configured fonts in the PS file, even those that will never be used. It does this by parsing itself the font files; Hmmm. I think something has changed here since I last looked at it. Jeremias? I have recently implemented Type 1 embedding for those fonts which have the PFB file specified. Before that all Type 1 fonts were only referenced, their encoding redefined to WinAnsi and assigned a font key which is used inside the pages. snip/ Jeremias Maerki
RE: PSDocumentGraphics2D and Font dictionary
Jeremias Maerki wrote: And what about PCL? And SVG? And AFP? IMO, output format specific code should not appear in the main interfaces for font access. Every target platform will have their little specialities: special font formats, font conversions may be necessary (Type 1 to SVG fonts, SVG fonts to Type 3). It makes sense to write font embedding code directly in the renderer. The font provider can certainly make the job easier by providing access to often-used data and especially to the raw font streams. But that may be limited to certain aspects of a font type or dependant on the font subsystem implementation. Providing a font to a layout engine has also different requirements than embedding or using a font in a specific I agree with all of this, and this type of project is somewhere way down my mental to-do list. However, it requires more knowledge than I have of all of the various rendering possibilities to be able to factor out the lowest-common-denominator. The existing methods can best be thought of as workarounds. output format. Maybe the Font interface should simply have a method to return a very generic interface for more detailed and font- and output-system-specific access to the font. Consumers of this interface can then cast it to a special interface/class. Something like: TargetFormatHelper Font.getTargetFormatHelper(String mime) Subclasses of TargetFormatHelper could be PDFTargetFormatHelper or a PSTargetFormatHelper. The Font This is an interesting idea, but, if I understand it correctly, breaks pluggability. interface in aXSL seems to be overloaded already, so this might be an improvement anyway. I don't understand this comment. It is a high-level abstraction. Here's my summary of the current discussion: 1. Currently the Fop PSRenderer embeds all of the configured fonts in the PS file, even those that will never be used. It does this by parsing itself the font files; 2. I can't reproduce this behavior with aXSL and FOray easily, because I've no direct access to the font files; Which is a problem IMO. See my comments above. I *really* don't understand this. The whole point of the font subsystem is to hide as much detail as possible from the client application. If you want access to the raw font data, then perhaps the FOP 0.20.5 approach is better for what you need??!! 3. Still doing this would require hacking the FOrayFont subpackage; that would result in something dirty but that should work; I believe this can be designed in way that is even cleaner than it is now. I just wish I had time to participate but my priorities make that impossible. 4. Anyway there are several improvements to bring to the PS renderer: mainly character encoding, font embedding and in a longer term two-pass rendering for a proper font handling. Now I'm thinking of the next release: simply putting the font name in the postscript file would be rather straightforward to implement, and should work for most of cases (?), thanks to the non-standard but well-known base14 (and even base35) font set. Without the knowledge on how to access a glyph outside the default encoding, characters like the very important Euro character will be impossible to produce. Again, I am lost. The *only* way you get to characters outside the standard encoding is to specify a different encoding. We know how to do that. But that's definitely a regression from the current state. Improving the PS renderer to allow proper embedding will require (1) changes to the aXSL interfaces (so a certain amount of discussions), (2) me to learn Postscript. That would prevent the FOrayFont subsystem from being integrated in the pre-release. If aXSL-font provides access to the raw underlying font streams, that problem basically dissolves. The following would certainly be no problem: InputStream Font.getRawStream(String part) where part may be pfb, pfm, afm, ttf etc. Is this just for embedding purposes, or do you intend to parse it? If you want to parse it, why? If all you want to do is embed it, why do you want the metrics files? FOray essentially provides the raw font stream now. It works for PDF, but, if I understand Vincent correctly, does not work for PS. So how does this method you suggest help that? Do you agree with my summary? Integrating FOrayFont in the pre-release would be great... Quite unrealistic as it stands now, sorry. That is your (FOP's) decision, but it makes no sense to me. You are willing to go backwards in almost any other area, but are unwilling to *not* go forwards with PostScript font embedding? Even when it is doable? Still, I appreciate knowing. I'll shift my focus back to getting my FOray release out the door. Victor Mote
RE: PSDocumentGraphics2D and Font dictionary
Jeremias Maerki wrote: I have recently implemented Type 1 embedding for those fonts which have the PFB file specified. Before that all Type 1 fonts were only referenced, their encoding redefined to WinAnsi and assigned a font key which is used inside the pages. OK. That should make it pretty easy for someone to patch FOray to do something similar. I'll get to it when I can. Victor Mote
Re: PSDocumentGraphics2D and Font dictionary
Victor Mote a écrit : I am not sure what you mean getPDF/PSSubset. If I'm correct it is only possible to embed the whole font file in a pdf output, by using getPDFFontFileStream. Currently aXSL doesn't seem to provide a means to embed only a subset. Point me to the FOP code that does the embedding, class name(s) and line numbers, and I'll see if I can extract it into an aXSL-exposed method. The whole code is in the class render.ps.PSFontUtil, mainly the method embedType1Font. 3. Still doing this would require hacking the FOrayFont subpackage; that would result in something dirty but that should work; Better would be to just make aXSL provide what needs to be provided. If we can hack FOray to do it, then we should be able to expose what is needed. Since nothing we are talking about here is a pollution of the interface, we should just be able to change the interface. On this point I was more thinking of a quick short-term solution for the pre-release, before taking the time to think about a clean implementation. 4. Anyway there are several improvements to bring to the PS renderer: mainly character encoding, font embedding and in a longer term two-pass rendering for a proper font handling. OK. I am confused. I thought above that font embedding worked in PS now, but this seems to indicate that it does not. Sorry, it also is a bit unclear to me. I think the precise status is the following: 1. font embedding only works with Type1 font for which a pfb file is provided (or also a pfa?). Subsetting --provided that this is specified by the postscript standard-- does not work; 2. currently only the WinAnsi charset seems to be supported. Fonts are systematically reencoded to this charset I can take some of this burden off of you, in that I can hopefully fix aXSL and FOray to provide what is needed. If that is done well, you shouldn't need to learn too much PostScript to get it to work, and perhaps one of the other developers can help you get it glued in. I don't know how much work it will take for me to get the FOray PS Renderer working (it may work now), I can use that as a test bed also. I appreciate your offer to help! Today I quickly launched the FOray PS Renderer but it doesn't seem to work. I haven't investigated, though, this may be a minor problem. Vincent
Re: PSDocumentGraphics2D and Font dictionary
Victor Mote a écrit : Jeremias Maerki wrote: output format. Maybe the Font interface should simply have a method to return a very generic interface for more detailed and font- and output-system-specific access to the font. Consumers of this interface can then cast it to a special interface/class. Something like: TargetFormatHelper Font.getTargetFormatHelper(String mime) Subclasses of TargetFormatHelper could be PDFTargetFormatHelper or a PSTargetFormatHelper. The Font This is an interesting idea, but, if I understand it correctly, breaks pluggability. aXSL and FOray easily, because I've no direct access to the font files; Which is a problem IMO. See my comments above. I *really* don't understand this. The whole point of the font subsystem is to hide as much detail as possible from the client application. If you want access to the raw font data, then perhaps the FOP 0.20.5 approach is better for what you need??!! To go a bit along with Victor, the font subsystem should perhaps provide more services, depending on the client (= the type of renderer): * a font abstraction like it is now for the layout part; * font manipulation facilities, like e.g. embedding and subsetting for the PDF renderer, conversion Type1 - SVG for the SVG one, etc. In fact I would rather put your proposed classes at the font subsystem level. If aXSL-font provides access to the raw underlying font streams, that problem basically dissolves. The following would certainly be no problem: InputStream Font.getRawStream(String part) where part may be pfb, pfm, afm, ttf etc. Is this just for embedding purposes, or do you intend to parse it? If you want to parse it, why? If all you want to do is embed it, why do you want the metrics files? FOray essentially provides the raw font stream now. It works for PDF, but, if I understand Vincent correctly, does not work for PS. So how does this method you suggest help that? See just above. Integrating FOrayFont in the pre-release would be great... Quite unrealistic as it stands now, sorry. That is your (FOP's) decision, but it makes no sense to me. You are willing to go backwards in almost any other area, but are unwilling to *not* go forwards with PostScript font embedding? Even when it is doable? Still, I appreciate knowing. I'll shift my focus back to getting my FOray release out the door. Victor, from a non-native speaker POV you seem to be a bit overreacting here. I have the feeling that I have misled you because of my bad understanding of the problem. I'm sorry if this is the case. Jeremias has a better vision of the situation than me, and I quite agree with him that the integration won't be ready for the pre-release. This does not mean that it will never be done. And after all, all the better: we will have more time to discuss about a clean API. Regards, Vincent P.S.: that said, the PDFRenderer should now work fine with the new font system; converting the SVG library should be pretty easy; this basically works for the AWT viewer. Nothing perfect, but... ;-)
RE: PSDocumentGraphics2D and Font dictionary
Vincent Hennebert wrote: I am not sure what you mean getPDF/PSSubset. If I'm correct it is only possible to embed the whole font file in a pdf output, by using getPDFFontFileStream. Currently aXSL doesn't seem to provide a means to embed only a subset. OK. I understand. Yes, subsetting only works for TrueType fonts. I built a rudimentary PostScript interpreter that is currently only used for parsing some of the metrics out of PFA/PFB files, but which should eventually be able to help us subset Type 1 fonts. Point me to the FOP code that does the embedding, class name(s) and line numbers, and I'll see if I can extract it into an aXSL-exposed method. The whole code is in the class render.ps.PSFontUtil, mainly the method embedType1Font. Thanks, I'll work on that. Sorry, it also is a bit unclear to me. I think the precise status is the following: 1. font embedding only works with Type1 font for which a pfb file is provided (or also a pfa?). Subsetting --provided that this is specified by the postscript standard-- does not work; 2. currently only the WinAnsi charset seems to be supported. Fonts are systematically reencoded to this charset OK, that is consistent with what Jeremias said. I understand where FOP is now. I can take some of this burden off of you, in that I can hopefully fix aXSL and FOray to provide what is needed. If that is done well, you shouldn't need to learn too much PostScript to get it to work, and perhaps one of the other developers can help you get it glued in. I don't know how much work it will take for me to get the FOray PS Renderer working (it may work now), I can use that as a test bed also. I appreciate your offer to help! Today I quickly launched the FOray PS Renderer but it doesn't seem to work. I haven't investigated, though, this may be a minor problem. I think you may have the honor of being the first person to ever use it :-) I'll see if I can get it working at some basic level. Victor Mote
RE: PSDocumentGraphics2D and Font dictionary
Vincent Hennebert wrote: Integrating FOrayFont in the pre-release would be great... Quite unrealistic as it stands now, sorry. That is your (FOP's) decision, but it makes no sense to me. You are willing to go backwards in almost any other area, but are unwilling to *not* go forwards with PostScript font embedding? Even when it is doable? Still, I appreciate knowing. I'll shift my focus back to getting my FOray release out the door. Victor, from a non-native speaker POV you seem to be a bit overreacting here. I have the feeling that I have misled you because of my bad understanding of the problem. I'm sorry if this is the case. Jeremias has a better vision of the situation than me, and I quite agree with him that the integration won't be ready for the pre-release. This does not mean that it will never be done. And after all, all the better: we will have more time to discuss about a clean API. You didn't mislead me at all, nor did you do anything else wrong. On the contrary, I appreciate your efforts greatly. WRT me overreacting, perhaps I have been misunderstood. The font system works well enough for what FOray needs ATM, but there are a lot of other things that don't. I have rearranged my priorities to try to make sure that I am not a bottleneck on any of this for FOP. I guess this made it higher on my priority list than it was on FOP's, which is pretty stupid. So, having now a better understanding of where everyone else's priorities are, I am glad for the opportunity to adjust mine back to where they really ought to be anyway: FOray. P.S.: that said, the PDFRenderer should now work fine with the new font system; converting the SVG library should be pretty easy; this basically works for the AWT viewer. Nothing perfect, but... ;-) That is good news, and I think you should be applauded for your efforts here. Victor Mote
Re: PSDocumentGraphics2D and Font dictionary
Well, so there is no simple solution :-( I could probably add a method like getConfiguredFonts in the font server to put in the postscript file all of the fonts defined in the config file. But that really sounds dirty to me. A temporary solution (before implementing a two-pass approach) would be to only support Base14 fonts; BTW, are these fonts well defined in the postscript standard? Or do they only exist in PDF? And a somewhat related question: how does font embedding work in postscript? I believe that it is like in PDF: embedding is not mandatory, one can simply put the font name in the file, and this will work if the corresponding font is installed on the client system. So this should almost always work for the fonts corresponding to the PDF Base14, and not always for others. Is there a font-naming convention? So, depending on the answers to the preceding questions: what do we choose? Systematic font embedding or only putting the font name? Thanks, Vincent Jeremias Maerki a écrit : I know exactly what you mean. The only way around this is to do a two-pass approach when writing PostScript, meaning that you keep track of resources (like fonts) while writing the pages and later you put together the complete PostScript document by including the needed resources in the right places. Obviously, that means loosing a lot of processing speed. PDF is in a better position because it's a random-access file format while PS is streaming. We can add the font objects to the PDF after we've already used them. On the other side, the PDF generated this way cannot be not a linearized file which allows Fast Web View. The browser always has to load the whole PDF file to display it because the cross-reference table is at the end of the file. So, even PDF has, in a way, the same problem. So you see: the problem is speed versus beauty. BTW, that was the reason why I started introducing a better resource handling with PS support, so we can later add such a mode where we write the PS file in a two-pass approach. On 12.09.2005 21:40:11 Vincent Hennebert wrote: In PSDocumentGraphics2D.writeFileHeader (and also in PSRenderer.startPageSequence) the font dictionary is written into the PS file by a call to PSFontUtil.writeFontDict. At this time all of the fonts present in the fontInfo (defaults + those found in the config file) seem to be written out, even those that won't be used in the fo file. I'm a bit worried because I can't reproduce that easily with FOrayFont. All I can get is the set of fonts that were used within the document. I guess that rendering starts as soon as possible and that at the time when the file header is written out the whole document may not have been entirely parsed yet? (but the PDFRenderer only stores used fonts by making a call to FontInfo.getUsedFonts!? This also is the case in PSRenderer.stopRenderer). So the question is: is there a mean to only put used fonts when writing out a PS font dictionary? This would be cleaner anyway. I hope I'm clear. Vincent Jeremias Maerki
Re: PSDocumentGraphics2D and Font dictionary
On 13.09.2005 00:53:56 Vincent Hennebert wrote: Well, so there is no simple solution :-( I could probably add a method like getConfiguredFonts in the font server to put in the postscript file all of the fonts defined in the config file. But that really sounds dirty to me. A temporary solution (before implementing a two-pass approach) would be to only support Base14 fonts; Yes, that's an option, though it's not one I like very much. The other option is to create an extension element to be put as a child into the fo:declarations element and attached to the document using the new ExtensionAttachment functionality to provide a hint to the PostScript renderer which fonts are actually going to be used in the whole documents. Something like: fo:declarations ps:supplied-fontsGaramond,Garamond-Bold/ps:supplied-fonts /fo:declarations BTW, are these fonts well defined in the postscript standard? Or do they only exist in PDF? PDF was derived from PostScript, so yes, they are well-defined. And a somewhat related question: how does font embedding work in postscript? I believe that it is like in PDF: embedding is not mandatory, one can simply put the font name in the file, and this will work if the corresponding font is installed on the client system. So this should almost always work for the fonts corresponding to the PDF Base14, and not always for others. Is there a font-naming convention? Font embedding is indeed very similar to PDF and no, I don't think there is a font-naming convention that you can rely on in every case. So, depending on the answers to the preceding questions: what do we choose? Systematic font embedding or only putting the font name? If the current approach is very difficult to implement, then I think it's best to use the approach with the renderer hint. I can implement that for you if you want. Only referring to the font name will not work since we currently have to reencode each font to the WinAnsi charset. And since each PostScript page should be self-sufficient and removable, we can't do this reencoding when the font appears for the first time. I will also need to check with my client if the renderer hint approach would be acceptable. Thanks, Vincent Jeremias Maerki a écrit : I know exactly what you mean. The only way around this is to do a two-pass approach when writing PostScript, meaning that you keep track of resources (like fonts) while writing the pages and later you put together the complete PostScript document by including the needed resources in the right places. Obviously, that means loosing a lot of processing speed. PDF is in a better position because it's a random-access file format while PS is streaming. We can add the font objects to the PDF after we've already used them. On the other side, the PDF generated this way cannot be not a linearized file which allows Fast Web View. The browser always has to load the whole PDF file to display it because the cross-reference table is at the end of the file. So, even PDF has, in a way, the same problem. So you see: the problem is speed versus beauty. BTW, that was the reason why I started introducing a better resource handling with PS support, so we can later add such a mode where we write the PS file in a two-pass approach. On 12.09.2005 21:40:11 Vincent Hennebert wrote: In PSDocumentGraphics2D.writeFileHeader (and also in PSRenderer.startPageSequence) the font dictionary is written into the PS file by a call to PSFontUtil.writeFontDict. At this time all of the fonts present in the fontInfo (defaults + those found in the config file) seem to be written out, even those that won't be used in the fo file. I'm a bit worried because I can't reproduce that easily with FOrayFont. All I can get is the set of fonts that were used within the document. I guess that rendering starts as soon as possible and that at the time when the file header is written out the whole document may not have been entirely parsed yet? (but the PDFRenderer only stores used fonts by making a call to FontInfo.getUsedFonts!? This also is the case in PSRenderer.stopRenderer). So the question is: is there a mean to only put used fonts when writing out a PS font dictionary? This would be cleaner anyway. I hope I'm clear. Vincent Jeremias Maerki Jeremias Maerki
