Re: Complex Script Support - Trac Site Access
Hi Glenn, Glenn Adams wrote: more On Thu, Aug 5, 2010 at 8:20 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Aug 5, 2010 at 7:18 PM, Vincent Hennebert vhenneb...@gmail.comwrote: Hi Glenn, From you first message I had the impression that you wanted to keep using that tool for future documentation as i've said, i intend to transition the documentation to the FOP wiki over a period of time, so that it will all end up on the latter we've pretty much exhausted this thread, but perhaps it would be clearer to you if you view the trac wiki site I am using as a working copy, sandbox or as a staging area as I compose my ideas and documentation; i could have merely done it on my local drive or on a private server, but i preferred instead to make it visible early, even though it is in preliminary stage which does not meet the standards I would expect for documentation that is promoted to the FOP wiki; i very well may rip up, rewrite, replace, restructure, etc., the content i am composing on my trac wiki before i feel it is ready for the FOP wiki; as I say, i could be doing that privately, but then interested viewers would not have early access to my preliminary work; overall, it is to your and the communities benefit that i choose to expose this preliminary work, with all its defects plainly visible; That’s fair enough, but you’re describing the very purpose of the FOP wiki here :-) Moreover, notification is sent to the fop-commits mailing list whenever a change is made to the wiki, which allows us to easily follow people’s progress. Vincent
Re: Complex Script Support - Trac Site Access
I've noticed that this has changed: Wiki changes are notified to fop-dev list. -- Pascal Le 06/08/2010 12:09, Vincent Hennebert a écrit : Moreover, notification is sent to the fop-commits mailing list whenever a change is made to the wiki, which allows us to easily follow people’s progress.
Embedding font from jar
I created some embedded code using EmbedFontInfo to load custom font files into the Renderer setFontList and setupFontInfo methods. I have a program with embedded Java running on the server which is working fine for creating a PDF and getting output to a printer. Now I'm trying to use client Java through Webstart to get the awt PreviewPanel working and it doesn't like the file path to the fonts. I'm trying to simplify file references by putting fonts, images in a jar. That jar should be on the classpath and the server and client should be able to reference the files in it the same way. I recompiled my FOP 0.95 jar to embed those files. I can put them in a separate jar if it makes more sense. Is there a simple way to reference the jar font file from embedded code? I tried creating an EmbedFontInfo object using jar:file:c:/web/public/fop.jar!/Fonts/LTYPEB.TTF for the embedFile parameter, and it crashes on the createFont method in the CustomFontMetricsMapper object. WARNING: Unable to load custom font from file 'jar:file:c:/web/public/fop.jar!/Fonts/LTYPEB.TTF' java.io.IOException: Problem reading font data. at java.awt.Font.createFont(Unknown Source) at org.apache.fop.render.java2d.CustomFontMetricsMapper.initialize(CustomFo ntMetricsMapper.java:109) ...
Dropping Support for Old Renderers
Hi, The new rendering architecture based on a streamlined intermediate format and painters has been in place for more than a year now and hasn’t caused any big issue. New features are being added to the painters (PDFDocumentHandler/PDFPainter, PSDocumentHandler/PSPainter, etc.) and usually not backported to the renderers (PDFRenderer, PSRenderer, etc.). Also, the old renderers get in the way when changes and refactorings must be made to the libraries. Therefore, I propose to drop support for the old renderers and remove them from version control. Does anyone have any objection to that? Thanks, Vincent
