Let us treat this issue not as a RFE, and not as a 'user base origin'
issue - bus a technical bug, possibly specificly related to the Mac.
There might - ass well - be user errors involved too.
Prelimnary: I believe you primarily use Windows and Linux. And so: Did
you try out converting the document I described to PDF yourself? What
was the result?
Regarding the FAQ:
* Honestly, I believe the FAQ is slightly incorrect and unwise. Or
perhaps I should say that it was incorrect of you to point me to that
FAQ - why? Because the fragment URL to that FAQ is "#custom_pdf_fonts".
However, I do not have a custom PDF font issue. I need the basic, normal
fonts to work as expected: The correct advice would be to recommend
users to first of all try the button which tells FOP to embed the
standard Windows fonts. Why? Because those fonts most likely do contain
the characters. And so, if the user did press the standard Windows fonts
button and still get problems, it is **then** one needs to dig deeper.
Analysis:
* If the button for embedding the standard Windows font does not help,
then
1. either the characters you need are indeed rather uncommon (in the
sense that they do not appear in the standard Windows fonts) - and thus
the correct answer is indeed to ask users to embed their own fonts.
(However, the common Cyrillic fonts of Russian, Ukrainian etc
characters, or the common Hebrew characters or the common East Euoropean
Latin characters - neither of these are uncommon - these characters
should be available, as long as the standard Windows fonts are embedded.
It is simply the wrong answer to ask users to embed other fonts than the
standard Windows fonts if such characters are not available.)
2. Or (and this might often be more likely) the CSS reference (or
other stylesheet info) is incorrect, and perhaps the FAQ should mention
that possibility as well: On my Mac, if FOP does not find the specified
font, it seems to try to use the socalled "Times-Roman" font, which is
not the same as "Times New Roman". The 'Times-Roman" font does not
contain much more than the Mac Roman character set (roughly the same
charset as Windows 1252).
3. The last possibility is that there is a bug - or possibly a
caching issue etc (which is also a kind of bug) - in the FOP settings
with regard to the standard Windows fonts setting. In that case as well,
the Times-Roman font will be used.
With regard to point 3 above, my claim is that there is such a bug and
that this bug probably only exists on Mac. I also claim that there is a
workaround. See below. However, to be certain that there is such a bug,
this bug should be looked into by others as well, for replication. (When
I get home in a week, I can check my wife’s Mac ...) I could of course
be that there was something specific to my mac which caused this.
Regardless, the workaround I have found seemed to fix it. Again, see
below.
Some more details regarding the "Use Windows standard fonts" button of
the FOP settings:
1. 'Times New Roman': Like I said in my initial message, this font does
contain all my necessary characters. So it just weird that, when XMLmind
pretend to embed 'Times New Roman', I do not get those letters. It seems
like a bug.
2. On the Mac, we are also 'blessed' with another Times font, the
'Times.ttf' font - also known as "Linotype's Times Roman" - see the
"Uses"-section of the relevant Wikipedia page - here:
https://en.wikipedia.org/wiki/Times_New_Roman#Uses And I believe that
this is the font that FOP falls back to if it does not find any other
font. The "Linotype's Times Roman" does indeed not contain the necessary
characters. This is the main reason I wonder if this is a Mac-specific
issue. I simply wonder if, on a Mac, that button actually makes the FOP
use "Linotype's Times Roman" font.
3. The bug thesis is supported by the fact that, when I study the log
during the conversion, I can clearly see that it complains the the
characters are not available in the font called "Times-Roman" = the Mac
Times.ttf font (which, by the way, is located in
"/System/Library/Fonts/Times.ttc".
4. The bug thesis is further supported by the fact that, for the other
standard Windows fonts, the "Arial" fonts and the "Courier New" fonts -
these fonts seems to work as expected. For instance,
<code>КХцкҩҴӡӶЍщопр</code> works fine and so does <h1
style="font-family:sans-serif"> КХцкҩҴӡӶЍщопр</h1>. (NB: It
might be that Arial fonts actually need the same workaround as the Times
New Roman fonts - I am not 100% certain about that.)
5. Workaround: On my mac, I seem to have been able to fix the problem
the following way:
1. First I added the standard Windows fonts by clicking the button
for that in the FOP settings.
2. Then I deleted all the then inserted references to the Times New
Roman settings.
3. To be certain, I made a restart of the XMLmind XML editor
4. Then I manually added, to the FOP embedding settings, the Times
New Roman fonts myself by pointing to the font on my computer.
5. I restarted my XMLmind XML editor. And, in one case, I also
logged out and in again.
6. (I also performed step 1-5 for Arial, but it could be that this
was unnecessary.)
I now get the characters I need, simply by way of using the standard
Windows fonts button of the FOP settings. So, since I, manually deleted
and readded the Times New Roman fonts, I have been able to add and
remove the Times New Roman fonts by pressing the standard Windows fonts
button. I did have these character problems for a long while. This is
the reason I think it is a bug an not an error on my part.
Leif Halvard Silli
On 27 Nov 2018, at 9:17, Hussein Shafie wrote:
How to quickly and easily solve this issue is a FAQ:
---
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
(But you already knew that.)
I'm sorry but, given our the origins of customers, we see no reason to
spend time and efforts improving or automating the above workaround.
On 11/27/2018 09:01 AM, Leif Halvard Silli wrote:
Given a document (DITA topic or XHTML) with the following lines:
* Hebrew: מנס
* Basic Latin: øĀÅ
* Latin-1 Supplement: ÑÐÃÊŻƀ
* Latin Extended-A: ĘśƒLjljNJNJǕǿǾ
* Latin Extended-B: DžDžDŽƘƍȟɁɣɸDžDŽ
* Greek: ΚΤццѦЀЀΞΟΠΡυφιθ
* Cyrillic: КХцкҩҴӡӶЍщопр
Then, when converting the above document (be it a XHTML document or a
DITA topic) to PDF, I get this output:
* Hebrew: ###
* Basic Latin: ø#Å
* Latin-1 Supplement: ÑÐÃÊ##
* Latin Extended-A: ##ƒ#######
* Latin Extended-B: ###########
* Greek: ###############
* Cyrillic: #############
One can solve this issue by, in the settings for FOP, selecting (on
one’s computer) a font (such as DejaVu Sans) which contains those
characters, for embedding.
However, according to Apple’s Font Book app, the Times New Roman
font,
which is one of the Windows standard fonts, does contain all of the
above characters. And so, my initial attempts to solve this was by
editing the font settings of the conversion stylesheet. That,
however,
had no effect.
Question: So, after all, since Times New Roman contains those
letters,
why is it not enough to rely on the standard Windows fonts (for which
there is a button in the FOP settings)?
Further: If - for PDF - rendering of characters outside the Latin and
Basic Latin group of characters requires that the user manually
selects
a font, there ought to be somewhere an alert about this. Or - another
variant - why not insert a warning about this in the interface for
editing the conversion style sheet? When the user points to a font
which
is not as well embedded via the FOP settings, the alert could simply
tell the user to remember to also embed that font in the FOP
settings.
--
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
