I presume you are using the epub3 stylesheet, which is better supports
the current EPUB standard. The DocBook epub3 stylesheet imports the
xhtml5 stylesheet as its starting point. In the xhtml5 stylesheet,
banned attributes like @width in an <img> element are supposed to be
converted to a single @style attribute by processing the generated img
element in mode="convert.to.style".
So I'm not yet clear on is where that process is going wrong such that
you are seeing @width in your output. I'll need to investigate more.
Bob Stayton
[email protected]
On 3/25/2021 4:46 AM, Radu Coravu wrote:
Hi Philo,
So the problem which remains is that the XHTML docs from the generated
EPUB archive have the image reference looking like this:
<img src="image.jpg" width="50%"/>
right? Does this way of specifying the proportional width work with
the EPUB reader? So is it only a problem of validation errors reported
by the epub checker but actually the EPUB reader interprets the
proportional width correctly?
Probably the image width would need to be specified like this in the
XHTML output:
<img src="image.jpg" style="width: 50%; height: 50%"/>
The DocBook publishing is based on XSLT stylesheets, there is an XSLT
stylesheet named "graphics.xsl" located in the Oxygen installation here:
OXYGEN_INSTALL_DIR/frameworks/docbook/xsl/xhtml/graphics.xsl
with a template named:
<xsl:template name="process.image.attributes">
which could probably be overwritten with a Docbook customization to
produce a @style attribute instead of directly the @width attribute.
Maybe you can start a different thread for the double numbers in the
PDF output and attach a small DocBook sample to reproduce the problem.
Regards,
Radu
Radu Coravu
Oxygen XML Editor
On 3/25/21 04:45, Philo Calhoun wrote:
Thank you Robert and Richard for your suggestions:
The color issue was solved using your suggestion:
<para><phraserole="red">Step 1:</phrase> Description of Step 1 etc.
</para>,
and editing the docbook-epub.css.xml file in Oxygen XML to include:
span.red {
color: rgb(200,0,0);
font-weight: bold;
}
However, the issue of image scaling seems more problematic, as I have
different % scaling of different images within a single topic (from
25% to 100%). The only way I can see to make this work is to have the
conversion add some sub style of img, like img.half img.quarter etc.
and I’m not sure how to do it in docbook. I can edit the ePub in
Sigil and add that sub style of img, but I then have to add the
designation for each and every image file, and that is a lot of work.
I am also having issues with pdf output of cross-references. They
work fine in ePub but generate double numbers in pdf. I’m fairly new
to Oxygen XML and docbook, and understand I need to brush up on the
conversion algorithms.
I am not using the docbook bibliography designation, as it seems
pretty complicated for the mixed types of references (web links,
books journals, etc.). So I have the bibiography as a section and
designate the entries like:
<listitem>
<paraxml:id=“Smith01”>Smith, J. This is my title. Scientific Journal
2021; 37(4):435-438. </para>
</listitem>
And cross reference like:
[<linklinkend=“Smith01"/>]
As a background, I have a couple of books that need to be in both pdf
and ePub outputs and have a lot of cross-references, tables, figures,
and mathematical formulas. I’ve used InDesign and Framemaker for them
in the past, but migrated to MadCap Flare. Unfortunately, while Flare
creates beautiful web output, its pdf and ePub outputs are buggy and
limited. This is particularly so with mathematical formulas and fine
tuning of the table of contents. I get about 95% of the way there,
but have to do a lot of creative workarounds due to problems/bugs
with Flare. Due to this frustration, I now publish the print version
using LaTeX, which works perfectly, but getting precise ePub output
without a lot of carryover junk code (the way Flare does) has been
much easier in Oxygen than in Flare. At this point, I still am having
to do a fair amount of precise formatting of the Oxygen generated
ePub in Sigil. (I tried Jutoh, but it corrupts MathML code
unfortunately.) My goal is to get both a clean output and specific
image formatting for ePub directly from OxygenXML. The extra level of
structure using XML vs XHTML is a huge benefit when it comes to
crossreferencing and maintaining consistent formatting.
Thanks again,
Philo
