Re: Specifying different generic font for different weights and styles

Hussein Shafie <[email protected]> Thu, 27 Feb 2014 19:12:10 +0100
Newsgroups gmane.text.xml.xfc.general
Message-ID <[email protected]>
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