Page 1 of 1

Ways to store CSS-accessible book metadata besides <bookmeta>?

Posted: Wed Jun 05, 2019 7:34 pm
by chrispitude
We store metadata about our book in a <bookmeta> element in the top-level bookmap file, like this:

Code: Select all

  <title>Our Product User Guide</title>
      <organization>My Company, Inc.</organization>
      <printlocation>Mountain View, CA</printlocation>
        <publishtype value="general"/>
      <prodname>My Product</prodname>
      <edition>My Version</edition>
Then I reference this metadata in our PDF Chemistry CSS via oxy_xpath() to populate the cover page and headers/footers, like this:

Code: Select all

*[class~="front-page/front-page-title"]::after(2) {
    content: "Version " oxy_xpath('//div[contains(@class, " bookmap/bookmeta ")]//div[contains(@class, " bookmap/edition ")]/text()') ", "
             oxy_xpath('//div[contains(@class, " bookmap/bookmeta ")]//div[contains(@class, " bookmap/completed ")]/div[contains(@class, " bookmap/month ")]/text()') " "
             oxy_xpath('//div[contains(@class, " bookmap/bookmeta ")]//div[contains(@class, " bookmap/completed ")]/div[contains(@class, " bookmap/year ")]/text()');

@page {
    @bottom-left {
      content: string(maptitle) "\a" oxy_xpath('//div[contains(@class, " bookmap/bookmeta ")]//div[contains(@class, " bookmap/edition ")]/text()');
and this works exactly as expected.

But in the merged XML file created by PDF Chemistry, the book metadata is propagated (duplicated!) in every single topic in the book. This metadata cascade is described as a requirement in the DITA spec ( ... tamap.html), but it contributes to a significant size increase in the merged XML file:

book_without_meta.xml: 4,794,623 bytes
book_with_meta.xml: 5,285,917 bytes

Half a megabyte of text overhead to store a handful of text strings is too much for my comfort, even for a temporary file.

I tried defining some key values in the top-level bookmap:

Code: Select all

  <keydef keys="version">
  <keydef keys="date">
        <keyword>June 2019</keyword>
but they don't get replicated in the merged XML file for me to access via oxy_xpath().

Is there another way to store and maintain book information that can be accessed from CSS? Or is there a way to disable this book metadata propagation in a transform?


- Chris

Re: Ways to store CSS-accessible book metadata besides <bookmeta>?

Posted: Fri Jun 07, 2019 3:06 pm
by Costin
Hi Chris,

There are two solutions for that:

- either select only the 1st instance of the content returned by the XPath, encapsulating each of your path expressions in parentheses (), followed by [1], like:

Code: Select all

*[class~="front-page/front-page-title"]::after(2) {
    content: "Version " oxy_xpath('(//div[contains(@class, " bookmap/bookmeta ")]//div[contains(@class, " bookmap/edition ")]/text())[1]') ", "
             oxy_xpath('(//div[contains(@class, " bookmap/bookmeta ")]//div[contains(@class, " bookmap/completed ")]/div[contains(@class, " bookmap/month ")]/text())[1]') " "
             oxy_xpath('(//div[contains(@class, " bookmap/bookmeta ")]//div[contains(@class, " bookmap/completed ")]/div[contains(@class, " bookmap/year ")]/text())[1]');
- or use a more specific path. For example, you should try collecting all "div" elements only from inside the div in the frontpage.
You could do that by adding somthing like:

Code: Select all

div[contains(@class, " front-page/front-page")]
at the very beginning of your path expression.

I hope this helps.


Re: Ways to store CSS-accessible book metadata besides <bookmeta>?

Posted: Fri Jun 07, 2019 5:29 pm
by chrispitude
Thanks Costin! Yes, I've used a similar solution in my own CSS.

I would really like to eliminate the duplicated metadata itself. Is there a way to (1) prevent the DITA-OT from such excessive duplication, or (2) is there another way besides the <bookmeta> construct to communicate data from DITA source files to the CSS files?

Maybe I could put the book information into a nonprinting DITA topic and access that...

Re: Ways to store CSS-accessible book metadata besides <bookmeta>?

Posted: Fri Oct 04, 2019 10:13 am
by Dan
Please read here:

The idea is to add to the metadata section of the bookmap data elements that expand the needed keys. We are not pushing all the defined keys in the merged map because there are cases of large key pools (thousands).