Thanks, Thomas. I hope I'll have time during the weekend to investigate further. We really need to get the XML Graphics Commons story forward somehow. If the PDFTextPainter were in Batik, there would have been no problem. As it stands right now, we would pretty much block our ability to release FOP until the next Batik release if we follow the changes in Batik Trunk. I guess we need to temporarily change the Gump descriptor to use the batik.jar in FOP's lib directory. That would at least allow you to proceed in the intended direction and you could remove GVT_FONT_FAMILIES again.
On 27.03.2006 15:34:44 thomas.deweese wrote: > Hi Jeremias, > > Jeremias Maerki <[EMAIL PROTECTED]> wrote on 03/27/2006 01:10:36 AM: > > > This change removes > GVTAttributedCharacterIterator.TextAttribute.GVT_FONT_FAMILIES > > which FOP's PDFTextPainter relies on. > > Hmm, yes it does. Sorry about that... > > > PDFTextPainter uses that list to determine if a font is an SVG font and > > needs to be painted as shapes instead of as text. Just FYI. I'll have to > > > find time to take a closer look. > > Actually this wouldn't be much of a problem, but it also uses it to > figure out the name of the font to use in the PDF. However this isn't > really the best, it should look at GVT_FONT to see what font has been > selected for each character/run of chars. Batik selects the font based > on it's ability to display the text. > > I've added an interface to GVTFont to get the font family name. > So eventually FOP can just use the GVT_FONT (or perhaps GVT_FONTS) to > do this selection (you can test if the GVTFont is an instance of > batik.bridge.SVGGVTFont like you do for font familes). > > I can add GVT_FONT_FAMILIES back for now, but it will have to go > away eventually since it nessesarily holds a hard ref to the font's > DOM (so the font instance can inherit properties from the text). It is > bad for our GVT tree to hold hard refs to the DOM. > > > On 26.03.2006 16:57:02 deweese wrote: > > > Author: deweese > > > Date: Sun Mar 26 06:57:00 2006 > > > New Revision: 388912 > > > > > > URL: http://svn.apache.org/viewcvs?rev=388912&view=rev > > > Log: > > > 1) SVG Text no longer forces reference to SVG DOM for static content, > > > when using AWT fonts. (SVG Fonts currently still hold a reference > > > to the SVG Document). > > > > > > 2) In most places TEXT_COMPOUND_DELIMITER has effectively been > > > replaced by TEXT_COMPOUND_ID. TEXT_COMPOUND_ID has a unique > > > value for each element in the DOM but retains no reference to > > > the element. > > > > > > In dynamic documents TEXT_COMPOUND_DELIMITER is still bound on > > > elements, with a hard reference to the DOM element. > > > > > > > > > Modified: > > > > xmlgraphics/batik/trunk/sources/org/apache/batik/bridge/SVGTextElementBridge.java > > > > > > xmlgraphics/batik/trunk/sources/org/apache/batik/bridge/svg12/SVGFlowRootElementBridge. > > java > > > > xmlgraphics/batik/trunk/sources/org/apache/batik/extension/svg/GlyphIterator.java > > > > xmlgraphics/batik/trunk/sources/org/apache/batik/gvt/flow/BlockInfo.java > > > > xmlgraphics/batik/trunk/sources/org/apache/batik/gvt/font/AWTFontFamily.java > > > > > > xmlgraphics/batik/trunk/sources/org/apache/batik/gvt/renderer/StrokingTextPainter.java > > > > > > xmlgraphics/batik/trunk/sources/org/apache/batik/gvt/text/GVTAttributedCharacterIterator. > > java > > <snip/> Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
