The writer no longer searches the list of classes for a known programming
language but always uses the first class in that list as the language
identifier.
Closes: #8814
The `\multicolumn` command takes the column type as the second argument.
Types like `p` take an additional argument, which is now ignored and no
longer causes the table parser to fail.
Fixes: #8789
The previous commit prevented header column cells from being dropped on
the floor, this one changes the paragraph style to "Table_20_Heading".
Note that for the test input, the result is not correct: the
AnnotatedTable type cannot represent the HTML input properly, as it only
has a concept of header rows and header columns, but HTML can have an
individual cell that is a header (not 100% sure but they way i read
https://html.spec.whatwg.org/#header-and-data-cell-semantics the <th>
cell here is both a row header cell and a column header cell while the
other cells in the row and column are not header cells), and header
cells may even appear "in the middle" of a table (see example in
https://html.spec.whatwg.org/#the-th-element).
So while this appears like it's the right thing to do for
Writer.OpenDocument, it's not clear if this is going to make things
better or worse overall.
Fixes: #8764
While ODF 1.3 part 3 does specify a 9.1.11 <table:table-header-columns>
element, in practice it's only implemented by spreadsheet applications,
not word processors.
So simply treat the row header columns as ordinary table columns, at
least they don't get lost then.
Fixes: #8764
The only element in meta for which data/templates/default.opendocument
allows block element content appears to be "abstract", which is already
filtered out of meta' at this point, so simply convert all blocks to
linebreak-separated inlines.
Fixes: #8256
The way "ooo:configuration-settings" work is that if LibreOffice Writer
loads a file in which it exists, it assumes that an old version of
itself has produced it and it defaults any config-item that it knows but
that doesn't exist in the file to the "backward-compatible" value, which
usually means to enable some layout or text formatting bugs so that the
document looks the same as in the old LO version that created it.
If there is no "ooo:configuration-settings" then it will use the default
values for a new document, which should give the best formatting
results.
Pandoc's documents are obviously not created by LO, so it doesn't make
sense to produce ooo:configuration-settings.
Regarding the "ooo:view-settings", IIRC these mainly set to the
document view to the position where the document was last edited (by
default only if the user in meta.xml matches the user data in LO's
configuration), which is also irrelevant for Pandoc.
So just leave out the settings.xml; only content.xml/styles.xml are
required (see ODF 1.3, part 3, 2.2.1 OpenDocument Document, A.2).
(The settings.xml that is produced for formulas by the documentSettings
function hopefully isn't problematic because LO Math works a bit
differently and stores important formatting attributes in settings.xml
because MathML doesn't allow it in content.xml.)
See ODF 1.3 part 2, 4.16.14.1 <manifest:file-entry>:
The manifest:version attribute specifies the format version of a file
entry. For documents that are composed from multiple files, this
attribute is specified at the manifest entry that references the
folder that contains these files.
The ODF validator complains about an invalid attribute
style:contextual-spacing in styles.xml, ultimately an implementation
error in whatever old version of LibreOffice that produced the
data/odt/styles.xml (should have put it into an extension namespace).
Fortunately the attribute was added to ODF 1.3, which was released a
couple years ago.
So the easiest fix is to simply produce ODF 1.3 instead of 1.2; it's
supposed to be fully backward compatible.
The section about pandoc's template syntax used to state that
spaces and tabs following the closing delimiter around variables
and control structures will be ignored. Some quick testing with
pandoc version 2.9.2.1 suggests that this is not the case. Spaces
and tabs _preceding_ the closing delimiter, however, are indeed
ignored. I therefore assume that this is simply a slight inaccuracy
in the manual; possibly produced by copying the sentence about the
opening delimiter and forgetting to adjust that word.
With this change, the typst writer will omit the `#bibliography`
command when `citations` is not enabled. (If you want to use
pandoc's own `--citeproc`, you should combine it with
`-t typst-citations` to disable native typst citations.
Closes#8763.
John MacFarlane