Ah, ok, so as long as the XML document that I'm editing is UTF-8 or UTF-16, then xmlmind is inserting "0xWhatever", and if the current font set has a glyph defined for the character then it will display it in both XMLmind and in the raw XML file (if I open that in another editor) and otherwise it will display a placeholder. Regardless of whether or not the current font set has a glyph defined, however, the true character is still being inserted.
So my next action is to equip the publishing server with better fonts and tell XEP to use them. Thanks Hussein, Jeff. ----- Original Message ---- > From: Hussein Shafie <huss...@xmlmind.com> > To: Jeff Hooker <j...@itwriting.ca> > Cc: "xmleditor-support@xmlmind.com" <xmleditor-support@xmlmind.com> > Sent: Wed, September 1, 2010 1:39:13 AM > Subject: Re: [XXE] Character tool and XEP PDF generation > > Jeff Hooker wrote: > > Hmmm. Ok, read the FAQ, but it's not really the situation that I'm in. For >that > > > matter, we don't using XMLmind for publishing. > > > > For example, the XMLmind character sheet labeled: 0x2200 (Mathematical > > Operators) -- where is this being drawn from? I'm reading up on unicode > > and >the > > > distinctions between characters, glyphs, and font sets, but I'm still a >little > > > at sea in terms of what kind of data XMLmind is embedding; the glyphs are > > clearly visible in the XML file when I open it in Oxygen, so XMLmind is >indeed > > > embedding them; > > XMLmind XML Editor creates XML files containing *characters*. There is > no concept of ``embedding'' whatsoever. There is no real difference > between character 'a' and character 0x2200. The XML file just contain > inline character 'a' and inline character 0x2200 (if, unlike UTF-8 or > UTF-16, the chosen encoding does not support character 0x2200, then this > character is saved as ∀). > > > > it's XEP that is failing to recognize them, I assume because > > I've not yet given it the tools to do so. > > > > XEP fully recognizes characters such as character 0x2200. The problem > comes from the 14 standard PDF fonts which have no glyphs for such > characters. Therefore you need to tell XEP to use fonts other that 14 > standard PDF fonts (e.g. Arial, DejaVu). That's it! > > XMLmind XML Editor allows you do that *very* *easily* for XEP or for > FOP. If you don't use XMLmind XML Editor to publish your documents, then > you'll have to configure XEP manually. > > > > > I expect that I'm going to end up writing an extremely long configuration >file > > > for XEP that defines the unicode value for every single character that I >need to > > > use, but understanding what kind of data I'm veiwing when I'm looking at > > the > > > XMLmind character tool and how it's embedding it would be helpful. > > The XMLmind character tool is just a kind of virtual keyboard. It does > nothing special. It just inserts in the XML the character clicked upon. > > > > >> On 07/20/2010 12:59 AM, Jeff Hooker wrote: > >>> Do you guys have any guidance on how to make the characters available > >>> in > >> your > >> > >>> character tool play nicely with XEP? What kind of encoding is being > >>> used >to > > > > > > > > > > >>> embed the character information? When generating PDFs, the current > >> experience is > >> > >>> very hit and miss. > >>> > >> This FAQ also applies to the case you describe: > >> > >> When I convert documents written in Russian (or Polish or Czech or any > >> non-western language) to PDF, almost all characters are replaced by the > >> "#" character. Is there a workaround for this problem? > >> > >> See http://www.xmlmind.com/xmleditor/faq.html#custom_pdf_fonts > >> > > > > -- > XMLmind XML Editor Support List > xmleditor-support@xmlmind.com > http://www.xmlmind.com/mailman/listinfo/xmleditor-support > -- XMLmind XML Editor Support List xmleditor-support@xmlmind.com http://www.xmlmind.com/mailman/listinfo/xmleditor-support
