So, I'm confused. I put that exact string into an fo:inline. I'm running embedded code and I separated the XML-FO transform step from the FOP step. I'm just running a straight Oracle transform. My input is an XML file containing the string □ My transformer is created using an XSL file. My output is an FO file with that string converted to a square. I put that string into a Java String and get the value. It comes out the same as it went in. How do I get the value of the String as a square?
-----Original Message----- From: Christopher R. Maden [mailto:cr...@maden.org] Sent: Fri 9/2/2011 4:09 PM To: fop-dev@xmlgraphics.apache.org Subject: Re: How to translate characters? I overlooked a couple things here... so by way of explanation: On 09/02/2011 02:44 PM, Eric Douglas wrote: > I see. As I said I saw something in the FOP classes which appeared > to be looking for such a code and translating it, but I just pulled > up a .FO file and I see it's already translated to be > <fo:inline>?</fo:inline> so there must be something in the Oracle > Transformer. There is nothing in the Oracle Transformer doing this. When you pass XML+XSLT or raw FO XML to FOP, the first thing that happens is the XML is parsed. XML is a markup language (obviously): the information represented by: <fo:inline>?</fo:inline> <fo:inline>□</fo:inline> <fo:inline>□</fo:inline> <fo:inline>?</fo:inline> is not only identical in effect, but literally indistinguishable after parsing. Operating on the parsed document, you cannot tell these things apart. They each represent a single XML element (named inline in the FO namespace) with a single character of content, U+25A1 WHITE SQUARE. The Oracle Transformer is operating on that data: an element with content that is one character long. No lookup or mapping is done. > So it seems FOP just gets the actual square and still has to know > what character it maps to in the font. FOP gets the square which *is* a character. It knows which character it maps to because it *is* that character. What FOP doesn't know (at first) is which fonts have useful glyphs for that character. It looks through the fonts currently in scope (as specified in the list in the font-family property) to find the first one that does specify a useful glyph for that character.[*] ~Chris [*] Strictly, as I understand it, it looks for the font that best matches an entire string, as character-by-character font selection isn't implemented. But for a single-character string, it's the same thing. -- Chris Maden, text nerd <URL: http://crism.maden.org/ > "The present tendency and drift towards the Police State gives all free Americans pause." - Alabama Supreme Court, 1955 (Pike v. Southern Bell Tel. & Telegraph, 81 So.2d 254)
<<winmail.dat>>
