Facing pages

[Rudi Chiarito <nutello@xxxxxxxxxxxxx>]

[reposted for the third time, I hate Outlook]

Hi there.

I am trying to process a DocBook document (a book) using OpenJade1.3
and Norman Walsh's stylesheets. I have encountered a few problems,
which are mostly sorted out by now, in one way or another. I thought
that maybe others would benefit from my experiences and that as a
result both OpenJade and the stylesheets could be slightly improved.
There's also a request for help at the end which can be of interest
also for those who do not use OpenJade/DocBook/Norm's stylesheets.

What's "peculiar" - in the sense that apparently nobody's dealt and
thus solved with such issues - about my book is that I decided to use
facing pages with different values for inner and outer margins. All
of my experiments were done with the RTF backend and Word2000, I am in
the process of installing MikTeX and friends (=> more headaches
ahead).

First thing I did was setting the left and right margin and setting
%two-sides% to #t. To my disappointment, even though headers and
footers were correctly swapped on odd/even pages, margins weren't. I
looked up high and low and eventually found that OpenJade didn't
support it, while theoretically RTF does. So, after reading the RTF
specs and looking at RTFFotBuilder.cxx I solved the problem by adding
\margmirror after \facingp at line 927. It seemed to work, but the
weird thing was that whenever a chapter started on an even (or was it
odd?) page, the page number was printed on the wrong margin. After a
whole afternoon of experiments and analysis of the RTF file (a 500Kb
long beast), not to mention rereading the RTF specs another three
times (I never had inspected RTF before), I realized that it was due
to chapters having different headers/footers on their first page.
Apparently they are output with the assumption that the first page
occurs on an odd (even?) page. As a quick fix I redefined
first-page-*-(header|footer) to output an empty sosofo, which gave
more correct results, at the cost of looking a bit ugly (no page
number on the first page of the Preface or the Glossary). That
happened a few months ago and I moved on other stuff, but the other
day I decided I'd fix it once for all.

Instead of settling with another quick hack, ie page numbers in the
center footer, I hacked print/dbcompon.dsl and redefined
$(left|center|right)-(header|footer)$ to ignore first pages altogether,
i.e. I commented out the if-first-page tests and the code executed when
they evaluate to #t.

This way, first pages simply use the margins set for other pages,
also correctly swapped for odd/even pages. This is where I am stuck now.
Basically things are working but I had to eliminate some functionality,
which has side effects in my case but not in many (most) others. So I
was considering a further improvement so that we can all be happy.

Custom footers/headers for the first page seem to work only when it is
already known in advance on which side it occurs. Everything would be
ok if some gentle soul implemented a new extension (and/or told me how to
start doing it, I know just RTFFotBuilder and ignore how the rest of
Jade works), i.e. a new force-first-page characteristic for
simple-page-sequence (borrowed from page-sequence). According to its
value (#f, front or back), the backend would output \sectd\plain (as it's
already being done now), \sectd\sbkodd\plain or \sectd\sbkeven\plain.
Or something like that.

Any comments? To me it looks like a simple solution without any major
cons (of course it's not strict ISO10179, but then page-sequence isn't
supported - yet?). I don't know if the TeX/MIF backend support something
like that already, IMHO it would be nice to have it available. I can
contribute with code/testing if anybody gives a first stab at adding the
new characteristic. Well, I know the former is much easier...

The second issue is purely about DSSSL code processing DocBook index
entries. Here's what I wrote to Norman a few hours ago together with
other questions, I would really appreciate if anybody else could help
in the meantime (I have some sort of deadline, the book is for a
potential employer overseas to review, I'll save you the other sad
bits):

--snip--
When an index entry has just one subentry (or when a subentry has
just one sub-subentry), it's probably a good idea to move the subentry
into the entry, as an entry modification or including the text into
parentheses. It looks much better than indenting the single subentry.
An example to make it more clear:

<indexentry>
 <primaryie>font
 </primaryie>
 <secondaryie>preferences editor,
  <ulink url="preferences.html#IDX-FONT-PREFS"
    role="IDX-FONT-PREFS">The System Preference Editors</ulink>
 </secondaryie>
</indexentry>

is currently rendered as

 font
   preferences editor, [page#(print)/containertitle(HTML)]

It could be output as

 font, preferences editor, [page#(print)/containertitle(HTML)]

OR

 font (preferences editor), [page#(print)/containertitle(HTML)] 

As a nice side effect, chances are that both new outputs will take
less space, which is a Good Thing (TM), but the most important thing
is that IMHO they look much better.
--snip--

Another precondition I failed to mention above is that the primaryie
element has no ulinks. If it has any, processing should be performed as
it is done now. 

Norm's code looks like this, of course it ought to be replaced with
much more logic:

(element primaryie
  (make paragraph
    (process-children)))

(element secondaryie
  (make paragraph
    start-indent: (+ (inherited-start-indent) 1em)
    (process-children)))

Can anybody help? I struggled with siblings and ancestors all night
long, but I couldn't find an acceptable solution. I sure need to practice
more... 

Happy New Year to those who bothered reading all of the above ;) 

-- 
Signature not present. Press Control-Amiga-Amiga to continue.
"I'll be thy master: walk with me; speak freely" (Cymbeline Act V Sc. 5)


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist