Renaud Richardet wrote (in Bugzilla): > http://issues.apache.org/bugzilla/show_bug.cgi?id=33760 > > Summary: [Patch] current AWTRenderer > Product: Fop > Version: 1.0dev
... > = Points I would like to discuss (see the corresponding FIXME > in the code) = > > Fonts: I must be missing something with the font-mechanism: > the rendered text in the AWTRenderer is smaller that the one > of PDFRenderer. What I need is a way to get a java.awt.Font > from an area. > Is the class FontSetup implemented correctly? Do I have to > worry about multibyte-stuff? > I could investigate the whole mechanism, but a hint would > certainly speed my work. Here are some things that may help: 1. FOray has factored the FOP font logic into a separate module, cleaned it up significantly, and made some modest improvements. A few weeks ago, I aXSL-ized it as well, which means that it is written to a (theoretically) independent interface: http://cvs.sourceforge.net/viewcvs.py/axsl/axsl/axsl-font/src/java/org/axsl/ font/ I say "theoretically" because the aXSL interface was simply extracted from the FOray code, and FOray is almost certainly the only aXSL implementation available ATM. The point is that someone *could* write another aXSL implementation that would work seamlessly with FOP. The only cost would be the instantiation of the brand X FontServer implementation instead of the FOray FontServer implementation. I think there is general support within FOP to implement the FOray/aXSL font work in the FOP 1.0 code, but so far no one has actually taken the time to do it. If you get into messing with fonts at all, I highly recommend that FOray be implemented before doing anything else. I will be happy to support efforts to that end. 2. The java awt Font-related classes don't give access to the underlying font file. This causes problems for the PDF renderer, which needs to be able to embed fonts in its output. Within FOray, the major distinction within the fonts is whether they are FreeStanding or System (awt) fonts. Embedding requires FreeStanding. AWT Renderer requires System fonts. There is some hope of merging the two at some time in the future, by using java.awt.Font.createFont method to create the AWT font from the application's (i.e. FOP/Folio/FOray) font registration system. However Java 1.3 & 1.4 only support TrueType fonts in this method, and 1.5 only adds support for Type1, so there are some built-in limitations. (FOrayFont doesn't support OpenType either, but it is very feasible to add that ourselves). 3. There are no doubt substantial improvements that can be made to the way aXSL/FOray handle the System font issue. I would be glad for someone who actually uses this aspect of the font system (I don't) to comment on it and suggest improvements. With the above as some background, I'll try to answer your questions: > the rendered text in the AWTRenderer is smaller that the one > of PDFRenderer. Some possibilities are 1) because of the dichotomy of the registration and selection of the fonts, you can actually be using different fonts for layout and rendering, 2) to the extent that the AWT renderer uses AWT to do the layout/rendering, there are bound to be differences between that and the way FOP does it. I wouldn't have expected font sizes to be a big issue, so maybe there is something else at work here as well. > What I need is a way to get a java.awt.Font from an area. The aXSL Font interface java.awt.Font getAWTFont(FontConsumer consumer, int fontSize) method. If the font is a System font, it will return the AWT font to you. The trick for you then is to be able to get the aXSL font instance out of the FOP FOTree or AreaTree. I'll defer to the FOP developers to tell you how to get that done. > Is the class FontSetup implemented correctly? It depends upon what you mean by "correctly". Like so many other things in FOP, it kind of works, but is very difficult to improve because of the underlying design. It is what evolved into the FontServer class in aXSL and FOray. Much of its data is static, which causes problems when running multiple documents in multiple threads (fixed in FOray). That may not be an issue for an AWT renderer, but is an issue when trying to develop a general solution that will also work for other renderers. IMO, the whole font subsystem had evolved into an unmanageable mess that needed a serious cleanup. However, that really is just an opinion. > Do I have to worry about multibyte-stuff? For screen display and java printing, I don't think so, since that is all handled by AWT. > I could investigate the whole mechanism, but a hint would > certainly speed my work. I am a FOP outsider these days, so maybe one of the committers can add some more insight. > I implemented a simple .bmp rendering (BMPReader.java). It > only supports 8-bit and 24-bit uncompressed windows bitmap > images. I found this code on the net. I know you had problems > with licences and I don't want to raise an issue here. I did > this implementation more for myself than anything. If there's > a better way to render .bmp (JAI?), let me know. Otherwise, I > could try to convince the author to donate the code in > conterpart of some fine chocolate :) FOP 0.20.5 handles BMP images OK. Looking at the FOP trunk code right now, there is a BmpImage class in package "image" and a BMPReader class in image.analyzer, so I am not sure what you mean here. Victor Mote
