chrischiasson / mmade Goto Github PK

What steps will reproduce the problem?
1. <<XML`DocBook`
2. DocBookInlineEquation["id",moment''[x]==0]

What is the expected output? What do you see instead?
DocBook markup.
We see:
XML`DocBook`Private`toString::usb: Can't convert moment''[x]==0 into a string.
$Aborted

Please use labels and text to provide additional information.
This happens because XML`DocBook`Private`toStringKernel calls
XML`DocBook`Private`unStringableBoxesQ after stripping unwanted boxes.
unStringableBoxesQ correctly flags the boxes
RowBox[{RowBox[{SuperscriptBox[moment,\[Prime]\[Prime],MultilineFunction->None],
[,x,]}],==,0}]
as unstringable because of the presence of MultilineFunction->None.

I think this can be fixed by removing all options before the string
conversion. I don't know if any of the possible box options will be
important to the string conversion process, but my guess is that they are
not. Accordingly, /.optionPseudoPatternObject->Sequence[] should be used
after stripping the unwanted boxes so that all the leftover box options
will be removed.

Right now, DocBookInlineEquationOptions is in the XML`DocBook`Private`
context, even though it is in Options@DocBookTable.

as instructed at
http://groups.google.com/group/alt.html/browse_thread/thread/7e37a47ba02e1c1b
so that typeset graphics will be in line with the rest of the text

Its default value should be None. It's a wonder the program runs without a
default value for Caption. Hrm.

so changes to styling or just markup can be viewed more quickly

if expr isn't a matrix, it will cause the code for determining the number
of columns to fail

What steps will reproduce the problem?
1. Put a string with a newline character ( \n ) into an entry in a table or
just make an entry with spaces that should line break if the table takes up
too much width.
2. Export the table with DocBookTable
3. Notice the newline character appears in the output xml (specific support
was added for this), but is ignored by the XSL processor such that the
table contains no newline after XSL transformation. If a long entry is
created instead, the problem with no line breaks is due to the lack of
automatic graphical line breaking (because the author did not specify
PageWidth explicitly). In addition, Firefox will not line break MathML
unless a new mrow is started, which Mathematica will not do (even if it is
fed a Cell object with an appropriately small PageWidth).

What is the expected output? What do you see instead?
A table with an entry that has a line break (or several line breaks). See 3.

Please use labels and text to provide additional information.
I propose adding a table entry parsing function that will "do what I want"
when given "typical" input. A "typical" entry in a table is a string of
space separated words, possibly with newline characters if the author is
trying to make a thin column. The next step up from that is a SequenceForm
containing more than one string and/or general expression. My parsing
function would be able to handle both of those. A third way of making a
table display with line wrapped columns is to use DisplayForm on a Cell
with its PageWidth Option set. A fourth way is to have content that, when
formatted, appears as the DisplayForm/Cell combo mentioned in step three.
My parsing function would not handle either of these two cases.

The entry parsing function should turn any top level SequenceForm into XML
sequences. All strings that are children of the top level SequenceForm or
that are themselves top level should be split into multiple string
sequences at word boundaries. Spaces should be preserved or added back in
after this string splitting. Hard new lines may be converted into line
break processing instructions. Any expressions that aren't strings should
be transformed in the regular fashion using DocBookInlineEquation. Since
the XML going into the source file will contain raw text instead of a
MathML object or graphic, the DocBook stylesheets should be able to line
break the entries as needed. BTW, any words that do not have spaces between
themselves and other objects that are exported by DocBookInlineEquation
should perhaps have a zero width space character inserted as a buffer to
provide a soft line break opportunity before the equation. See
http://www.oasis-open.org/archives/docbook-apps/200310/msg00130.html