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... ;-)
