DITA and XMetaL Discussion
Fa September 20, 2017 at 7:16 am
Plugin and RenderX: how to make them communicate?September 20, 2017 at 7:16 amParticipants 3Replies 4Last Activity 5 years, 4 months ago
I am having a very hard time figuring out how to deal with fonts. From my previous experience on XMetaL 6 with DITA-OT 1.3, it was quite straightforward: you would set the font in e.g. commons-attr.xsl to logical font (e.g. Serif), then you would tell in font-mappings what that logical font corresponds to (according to the language, if not specified it reverts to default), e.g. default is “DefaultFont”, Simplified Chinese is “CNFont”, etc. and then in XEP you would give the font data.
E.g. if I wanted DefaultFont to be Arial, then
And then when the text was translated into Chinese, and I wanted CNFont to be e.g. SimSun, I'd have
But I find that much has changed between 1.3 and 2.4, and there has probably has been much development in RenderX as well.
So I guess my first question is: does it still work like this (it doesn't seem so), and if it doesn't, what has changed?
And before I go any further, I also want to make sure that my plugin uses RenderX. I was under the impression that that was the default renderer that XMetaL uses, but I am not sure. Is it? If it is not, where do I set the renderer to be RenderX? (Or alternatively, how do I solve my problem using FOP?)
I have tried modifying the font data in the xep.xml file, but it doesn't seem to have any effect on my plugin output, not even on the English. However, changing the base-font in, e.g. common-attrs lets me choose the font I want for the pdf content, and the same goes for toc-attrs to select fonts for the TOC, etc.
Any hint is welcome!
FaDerek Read September 20, 2017 at 5:02 pm
Reply to: Plugin and RenderX: how to make them communicate?September 20, 2017 at 5:02 pm
Yes, it should still function basically the same. RenderX has not changed this functionality (at least not to any degree that would change this behaviour that I'm aware of). One thing that has changed is the values in these files. More fonts have been added to the list of Windows font paths and that section has been enabled (in older versions that section was commented out).
Though RenderX XEP is licensed and configured for use with the DITA OT included with XMetaL Author Enterprise I don't think you can say it is the default rendering because different deliverable types use different engines to create their output.
These deliverables use RenderX XEP:
Book via RenderX
Book via Structured FrameMaker
XMetal Enhanced PDF via RenderX XEP
XMetaL Enhanced PDF via RenderX XEP and Acrobat Distiller
This deliverable uses Apache FOP (also included):
PDF via FO with default processing
These deliverables use Antenna House XSL Formatter:
XMetaL Enhanced PDF via Antenna House XSL FormatterFa September 21, 2017 at 11:34 am
Reply to: Plugin and RenderX: how to make them communicate?September 21, 2017 at 11:34 am
Thank you for your answer, Derek.
I thought I had managed to get it to work, but I just tested and it's not working as I thought it should.
In my commons-attrs.xsl file, I have my base font set as:
Then I have applied that base font throughout the file using an __fo__root attribute set.
Note that I had to use “sans-serif”, while I thought that “Sans” would have been the obvious choice, but it did not work, although they are listed as aliases in my font-mappings.xml (and “Sans” works for my xmfo plugin!!!)
Using “Sans” reverts to using a serif font (I'm not sure which one and I have no idea where it gets it from).
Anyway, font-mappings.xml defines Sans (so sans-serif, too, if aliases work) as using Arial as default
From what I understand (and I've been able to test that using the xmfo plugin XMetal Enhanced PDF via RenderX XEP), Arial here is only a “face”, you then point to the font files in the xep.xml file. In xep, I have Arial defined as follows:
and I replaced the first font file with a totally different font, which makes the change obvious in the output:
This works [u]with the xmfo plugin[/u], i.e. I see the Bauhaus font used wherever the regular sans (or sans-serif) font should be used when generating, but I see no change in my own plugin.
Another very odd thing is that, as stated above, in the xmfo plugin, I can use “Sans” and not “sans-serif”, and it is recognized, but as I said, my own plugin only recognizes “sans-serif”.
So to summarize, my plugin applies the correct font when I refer to “sans-serif”, but when I use “Sans” (which works for xmfo), it just falls back to to a serif font, and I don't know what that fall back mechanism is, neither where the said serif font is defined. And this is very annoying, because before I figure that out for default (US English) documents, I won't be able to get my other languages to work with different fonts (Chinese at the moment only shows hashtags ## instead of the Chinese glyphs, although Sans and Serif are both mapped in Font Mappings and xep to Chinese fonts).
I'm kind of short of ideas about what to do or try next, so I'd really appreciate a small nudge in the right direction. Ideas anyone?
And by the way, is there a way to know for sure that my plugin uses renderX? Where is the pdf renderer defined?
FaDerek Read September 22, 2017 at 7:49 pm
Reply to: Plugin and RenderX: how to make them communicate?September 22, 2017 at 7:49 pm
Quick answer before I try to start digging into the other stuff.
To test if whatever deliverable you are using uses RenderX I would just change the name of the RenderX folder. That will break output. Change it back and it will work. If not, then it is using another rendering engine (the only other one installed with XMetaL Author Enterprise is Apache FOP; Antenna House XSL Formatter needs to be purchased and installed by you).
As for “Sans” vs “sans-serif”, those names are going to be used in the XSLFO (generated by the XSLT), so I think you should just search for them in the .xsl files inside the plug-in to see where they are called. Most likely “sans-serif” is used and “Sans” is not, in which case the “fallback” is going to be whatever default font family the PDF spec states is the default which will be one of Arial, Helvetica, Courier or Symbol (which make up the 14 default fonts that must be shipped with a PDF rendering engine, if it follows the PDF spec).Fa September 25, 2017 at 12:10 pm
Reply to: Plugin and RenderX: how to make them communicate?September 25, 2017 at 12:10 pm
Thank you Derek!
As I suspected, my plugin is not using XEP, but FOP. Even with the RenderX folder renamed it produces the same layout.
This might explain why the xmfo plugin recognizes “Sans”, and my custom plugin requires “sans-serif”. My custom plugin only uses sans-serif, serif and monospaced, I have no reference to any font name, so the “fallback” fonts are probably those you cited, referenced in the pdf2 plugin.
I have tried changing throughout my plugin all fop references to xep references, but that breaks the output.
The files I have modified are:
xsl/fo/topic2fo_shell_fop.xsl renamed to xsl/fo/topic2fo_shell_xep.xsl (I have also modified the integrator.xml file reference to the file to reflect this name change) and modified as follows:
In cfg/fo/attrs/basic-settings.xsl, I changed the line
Are there some files at a higher level (e.g. DITA_OT level) that would require editing for this to work, or is this the wrong approach?
Also, should I define another plugin under “require” in plugin.xml? Currently it is set to
- You must be logged in to reply to this topic.