Ok, thanks.
In the interim, I will see if I can write a style sheet or Java code
to modify the FO to include specific font family/weight/style,
rather than depend on subsequent steps to map "sans-serif".
I took a quick look at this already, but it is a bit ugly because
one has to track what is inherited from parent <fo:block/> elements.
David
On 2/27/14 1:12 PM, Hussein Shafie wrote:
First of all, please understand that, for several reasons, XMLmind
XSL-FO Converter cannot be compared to XSL-FO processors such as XEP,
Antenna House and FOP, which all generate PDF.
One of these reasons is font management.
Because by default PDF only supports 14 fonts
Times-Roman
Times-Italic
Times-Bold
Times-BoldItalic
Helvetica
Helvetica-Oblique
Helvetica-Bold
Helvetica-BoldOblique
Courier
Courier-Oblique
Courier-Bold
Courier-BoldOblique
Symbol
ZapfDingbats
and because these fonts have very few glyphs, all the aforementioned
XSL-FO processors are forced to embed subsets of third-party fonts in
the generated PDF file. This explains why all these tools have complex
configuration files and have an evolved way of specifying font mapping.
The situation is totally different for XMLmind XSL-FO Converter which
generates RTF, WML, DOCX and ODT files making use of whatever font is
available on the system where the word processor is being run.
This being said, XMLmind XSL-FO Converter exists since 2002 and you are
the first customer[*] to request this feature (which is: support not
only typeface mapping, but also font mapping). We would have implemented
this feature if there was a demand for it.
Now that
- we have a demand for it and
- that you have proved us that organizations generating multi-language
documents (very few of our customers indeed) are more or less forced to
stick to the ``lonely'' "Arial Unicode MS" font,
we'll seriously consider implementing the feature you want.
However this is unlikely to happen in the near future (we have released
v5 just a few days ago: http://www.xmlmind.com/news.html).
---
[*] Most of our customers are large western corporations (banks,
insurance companies, pharmaceutical companies, etc) generating XSL-FO
out of database contents using very specific, in-house, XSLT
stylesheets. Very few of our customers use the DocBook or DITA XSLT
stylesheets.
On 02/27/2014 01:48 PM, David Clunie wrote:
Well, you may not think it is useful, but your assumptions do
not hold in the general case.
Specifically:
1. "Arial Unicode MS" does NOT have italic and bold weight and
style variants.
2. "Arial Unicode MS" does have good support for all of the Asian
characters, which render very well, especially across multiple
platforms, which is why I use it a lot, without the need to
explicitly specify a different font for Asian characters or
detect the language tag and switch fonts in the stylesheets,
etc.
3. All other FO tools I have used (XEP, Antenna House and even FOP)
have the ability to selectively specify different font families
based upon weight (+/-bold) and style (+/-italic) and so they
do support my use case, where as yours does not.
To illustrate why this is useful, I have attached screenshots of
Word 2011 on the Mac rendering docx output from fo2docx using
no genericFontFamilies font information, using "Arial Unicode MS",
using ordinary "Arial", and using "Calibri" as you suggest.
You will note that only the "Arial Unicode MS" renders the
Japanese characters correctly, and sacrifices the bold for
the headings to achieve that goal.
By contrast, see the screenshot of the PDF output from XEP that
does distinguish fonts not only at the family but also at the
weight/style level, which is my "ideal" output (Asian characters
rendered well, plus bold for heading rendered).
If you can describe a way for me to achieve my objective that your
product supports that does not require this mechanism, e.g.,
identify a font that is freely available across all platforms,
looks as good as "Arial Unicode MS", supports all Unicode code
points AND contains italic and bold variants of them, then I
would be very happy to hear about it.
Otherwise this is IMHO a feature that your tools could benefit
from adding.
David Clunie wrote:
In case you think my use case is peculiar, by the way, here
is a long thread that explains the interest other folks have
in this class of problem:
http://www.unicode.org/mail-arch/unicode-ml/y2003-m06/0211.html
--
XMLmind FO Converter Support List
[email protected]
http://www.xmlmind.com/mailman/listinfo/xfc-support
