How to change codeph and codeblock styles?

261 views
Skip to first unread message

mrob

unread,
Feb 16, 2016, 12:43:47 AM2/16/16
to DITA-OT Users
Seems like this should be obvious but I'm having no luck.

I want to change the codeph and codeblock elements to use Arial Narrow in my PDF.

I'm following the helpful book DITA for Print, but I'm stuck on the instructions given there. For example, on p. 79, the book says that the codeph element is part of the sw domain, and all the attributes are in the sw-domain-attr.xsl file. (I assume that I should copy this file into the \cfg\fo\attrs directory of my plugin and edit the copy.) However, when I look in this file, I do not find any attributes for codeph.

Looking around in other files, I find the attributes for codeph in pr-domain-attr.xsl. So, I copy this file into my \cfg\fo\attrs directory and edit the copy, as follows.

First, I copied font-mappings.xsl to my plugin, and added the following:

    <aliases>
      <alias name="narrow">Narrow</alias>
    </aliases>

and further down in the file:

    <logical-font name="Narrow">
      <physical-font char-set="default">
        <font-face>Arial Narrow</font-face>
      </physical-font>
      <physical-font char-set="Simplified Chinese">
        <font-face>AdobeSongStd-Light</font-face>
      </physical-font>
      <physical-font char-set="Japanese">
        <font-face>KozMinProVI-Regular</font-face>
      </physical-font>
      <physical-font char-set="Korean">
        <font-face>AdobeMyungjoStd-Medium</font-face>
      </physical-font>
      <physical-font char-set="Symbols">
        <font-face>ZapfDingbats</font-face>
      </physical-font>
      <physical-font char-set="SubmenuSymbol">
        <font-face>ZapfDingbats</font-face>
      </physical-font>
      <physical-font char-set="SymbolsSuperscript">
        <font-face>Arial Narrow</font-face>
        <baseline-shift>20%</baseline-shift>
        <override-size>smaller</override-size>
      </physical-font>
    </logical-font>

Then, in pr-domain-attr.xsl, I edited the attributes like this:

    <xsl:attribute-set name="codeph" use-attribute-sets="base-font">
        <xsl:attribute name="font-family">narrow</xsl:attribute>
        <xsl:attribute name="font-size">9pt</xsl:attribute>
        <xsl:attribute name="background-color">#e6e6e6</xsl:attribute>
    </xsl:attribute-set>


I regenerate the PDF without errors, but nothing has changed. All my codeph-tagged text looks the same. I've tried the same with codeblock but no luck there either.

What am I doing wrong?

Are the instructions on p. 79 of the book incorrect, or should I add attribute definitions to sw-domain-attr.xsl, or ... ?

Thanks in advance

mrob

unread,
Feb 22, 2016, 10:27:52 PM2/22/16
to DITA-OT Users
Anybody?

I'm kind of stuck on this.

Or: suggestions for debugging, to try and find how/where my changes are not having the desired effect?

Thanks

Jarno Elovirta

unread,
Feb 23, 2016, 1:56:56 AM2/23/16
to mrob, DITA-OT Users
Hi,

Which DITA-OT version? Have you tried to make sure your override stylesheets are in use, i.e. do you have xsl:import elements for them in the shell stylesheet? Simply copying stylesheets to \cfg\fo\attrs will not take them into use, you have to explictly take them into use with xsl:import (or xsl:include).

J

--
You received this message because you are subscribed to the Google Groups "DITA-OT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dita-ot-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Julio Vazquez

unread,
Feb 23, 2016, 6:26:30 AM2/23/16
to DITA-OT Users
Did you define Arial Narrow as an alias in the font-mappings.xslt file? If not, the OT won't find the font.

Julio

Julio Vazquez

unread,
Feb 23, 2016, 6:31:10 AM2/23/16
to DITA-OT Users
Never mind. Posted too early in the morning. What you have looks right so the question is really, are you sure the font is installed?

Julio

Eero Helenius

unread,
Feb 23, 2016, 4:48:59 PM2/23/16
to DITA-OT Users
Also, which PDF formatter are you using? FOP, Antenna House...?

mrob

unread,
Feb 23, 2016, 8:16:35 PM2/23/16
to DITA-OT Users
Sorry, I should have mentioned this: I am using DITA-OT 1.8 and FOP.

I know this isn't the latest release, but I'm following the book DITA for Print, and it is based on 1.8. I'm still too much of a noob to interpolate differences between releases. This book already seems to have a few errors that are not covered in the errata, and that's enough for me to handle.

I am pretty sure that my font-mappings.xml file is being parsed. I can modify the physical font definition for "Sans" (e.g., add Trebuchet MS) and it changes the font in the PDF, just as I would expect.

Jarno, I'm not sure what you mean by "shell stylesheet".

The codeph and codeblock elements are declared in pr-domain-attr.xsl. So, in my custom.xsl file, I have the following line:

  <xsl:import href="pr-domain-attr.xsl"/>

Here's the content of custom.xsl:

  <xsl:import href="basic-settings.xsl"/>
  <xsl:import href="commons-attr.xsl"/>
  <xsl:import href="commons-attr_fop.xsl"/>
  <xsl:import href="hi-domain-attr.xsl"/>
  <xsl:import href="layout-masters-attr.xsl"/>
 <xsl:import href="pr-domain-attr.xsl"/>


Julio,

I am sure that Arial Narrow is properly installed as a TrueType font on my machine. I can use it in MS-Word and other apps.

What should I try next?

Thanks!


Erlend Leganger

unread,
Feb 23, 2016, 11:40:46 PM2/23/16
to mrob, DITA-OT Users
Can you try to change something different than the font to verify that your custom.xsl is really picked up? For example setting the font size to some insane, noticable value? 

mrob

unread,
Feb 24, 2016, 12:58:13 AM2/24/16
to DITA-OT Users, mrober...@gmail.com
I tried changing the font-size attributes for codeph and codeblock (in pr-domain-attr.xsl). Nothing happens. There is change in the output PDF.

Which custom.xsl file are you speaking of? attrs or xsl?

I have an xsl:import in the attrs custom.xsl. I've made no change to the xsl custom.xsl. Should I add something there?

mrob

unread,
Feb 24, 2016, 12:59:06 AM2/24/16
to DITA-OT Users, mrober...@gmail.com
Sorry, meant to say there is no change in the output PDF file.

Erlend Leganger

unread,
Feb 24, 2016, 2:02:27 AM2/24/16
to mrob, DITA-OT Users
Sometimes it is best to restart from scratch. If you start with a pristine DITA OT installation and follow the book to the letter, can you make any kind of change to the resulting PDF? I have the book myself but don't have it at hand here, so I don't remember exactly, but I'm pretty sure that there is a detailed example on how you can modify something in the resulting PDF. With that change in place, it is a matter of extending the method you already have used to change another thing, for example the font for the whole PDF from Times-Roman to Arial. Then you extend it again to change font for <codeph/>, <codeblock/> etc.

On 23 February 2016 at 21:59, mrob <mrober...@gmail.com> wrote:
Sorry, meant to say there is no change in the output PDF file.

--

mrob

unread,
Feb 24, 2016, 3:22:35 AM2/24/16
to DITA-OT Users, mrober...@gmail.com
Sorry, but I need a better solution. It is not practical to start over from scratch for this.

I can change definitions in font-mappings.xml and they appear in my PDF.

I have added a new logical-font "Narrow" and I am using that as the font-family for codeph and codeblock.

But, it doesn't work.

Is there no way to debug the operation of the DITA-OT?

If not, I am surprised and disappointed.

Kristen James Eberlein

unread,
Feb 24, 2016, 7:14:17 AM2/24/16
to dita-o...@googlegroups.com
Have you looked to see what is in the topic.fo file? That is one of the first places to go when troubleshooting a custom PDF plug-in.

Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 682-2290; kriseberlein (skype)

Radu Coravu

unread,
Feb 24, 2016, 7:20:54 AM2/24/16
to Kristen James Eberlein, DITA-OT Users
Also as a best practice, your custom.xsl should contain only the XSLT templates which are overwritten (which are modified in any way) without any imports.
Otherwise you might end up with other templates matching the elements that you want to customize. For example because of the way DITA inheritance works a template matching a class containing value " topic/ph " will also match all bold and italic element if its priority is higher because of the order of XSLT imports.

Regards,
Radu

Kristen James Eberlein

unread,
Feb 24, 2016, 7:43:16 AM2/24/16
to Radu Coravu, DITA-OT Users
My advice will differ from Radu's slightly ...

I think it's fine to have <xsl:import> statements in your xsl/custom.xsl file. Doing so has many benefits:
  • Helps you organize your overrides
  • Lets you know which DITA-OT file the original code was located in
  • Makes it easier to troubleshoot problems with your custom plug-in
But -- and here is where I am sure that Radu and I agree -- the XSL files that you import should contain ONLY the templates that you are overriding.

For example, if you want to override how <draft-comment> elements are handled, to ensure that the name of the person authoring the comment and the day that they made it are rendered:

1. Make a copy of commons.xsl in your plug-in.
2. Delete everything from the copy of commons.xsl, and add your override for <draft-comment>.
3. Import your copy of commons.xsl in your xsl/custom.xsl.

Ensuring that your custom plug-in only includes the templates that you are overriding is a best practice that helps isolate your code from that of the larger DITA-OT. It will make it MUCH easier to migrate your plug-in to new versions of the DITA-OT when they are developed.


Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 682-2290; kriseberlein (skype)

Julio Vazquez

unread,
Feb 24, 2016, 8:31:40 AM2/24/16
to DITA-OT Users
I agree with Kris. Instead of importing pr-domain.xsl, create a code.xsl that contains only the <code> and <codeph> attribute sets and import that. Try changing the color to red and see if that works. If not, something closer to the text is resetting the attributes. Look at the topic.fo to see if you can find that. Otherwise look for the template that processes the elements.

Julio

Julio Vazquez

unread,
Feb 24, 2016, 8:40:12 AM2/24/16
to DITA-OT Users
Just noticed something. We might have thought it was a typo. Did you create font-mappings.xsl or font-mappings.xml? If the former, rename it to the latter.

Julio

mrob

unread,
Feb 25, 2016, 10:41:34 PM2/25/16
to DITA-OT Users
I really appreciate all of this advice, but I must say again that I'm a noob to this framework and thus you are all pretty much speaking over my head. I've been using DITA for a few years now, but DITA-OT is another level.

Answering your messages in series:

Kristen,

I see that there is an option to preserve the topic.fo file, but if I change that flag and look inside the file, what exactly should I be looking for?

Radu,

I don't understand your suggestion, and Kristen seems to disagree, so I'm not sure how to act on this.

Kristen,

I have tried to follow your suggestion, combined with Julio's, but it changes nothing in the PDF output. Probably I am not understanding something and doing it wrong, so here are the details:

I have a copy of pr-domain-attr.xsl in fo/attrs. This file contains the definitions for codeph and codeblock. I mode only these two definitions into a new file called code-attr.xsl in fo/attrs. I then modified the definition for codeph by adding this:

  <xsl:attribute name="color">red</xsl:attribute>

And I added the following to fo/attrs/custom.xsl:

  <xsl:import href="code-attr.xsl"/>

I removed the import of pr-domain-attr.xsl from the same custom.xsl file.

Created the PDF file again. No change.

Julio,

I don't know what I'm supposed to be looking for in the topic.fo file. And lastly, yes, I have font-mappings.xml, not font-mappings.xsl. I believe this file name is shown incorrectly twice on p. 36 of DITA for Print, and this error is not mentioned in the errata. 

Thanks for all of this advice, and sorry again that I'm not following everything you propose.

mrob

unread,
Feb 25, 2016, 10:43:16 PM2/25/16
to DITA-OT Users
Sorry, typo in my message just now. It should be: "I move only these two definitions ...".

mrob

unread,
Feb 25, 2016, 11:20:00 PM2/25/16
to DITA-OT Users
Following up...

While trying to understand DITA classes, I figured out the problem. I didn't have the following line in my xsl custom.xsl file:

 <xsl:import href="pr-domain.xsl"/>

Adding this fixed the problem. I can now modify the appearance of codeph and codeblock.

I guess I still don't quite understand why there are two separate custom.xsl files, and what the xsl and attrs directories are really about, but maybe I'll get this later...

Anyway, thanks again much for your suggestions!
Reply all
Reply to author
Forward
0 new messages