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
