(That is, whenever we have the filename and are in a
PandocMonad instance.)
This will lead to more informative error messages for UTF8
encoding, indicating the file path and byte offset where the
error occurs. Closes#8884.
This is like `Text.Pandoc.UTF8.toText`, except:
- it takes a file path as first argument, in addition to
bytestring contents
- it raises an informative error with source position if
the contents are not UTF8-encoded
[API change]
This replaces `utf8ToText` in `Text.Pandoc.App.Input`.
See #8884.
This change sets RowHeadColumns to the minimum value of each row, which
gives better results in cases where rows have different numbers of leading th tags.
These changes recognize that parseURI does not unescape the path.
Another change is that the canonical form of the path used as the
MediaBag key retains percent-encoding, if present; we only unescape
the string when writing to a file.
See #8918.
Some tests are needed before the issue can be closed.
In the new code a comma mysteriously turned into a period.
This would have prevented proper separation of the mime type and
content in data uris. Thanks to @hseg for catching this.
While converting dokuwiki syntax to gfm, the query parameters of images were stripped from the output.
In general this makes sense, as the parameters' semantics are specific to dokuwiki. But it makes it impossible
to access the query in a filter. This change retains the query parameters of image urls in the dokuwiki reader,
by adding it as an extra query attribute.
This vulnerability, discovered by Entroy C, allows users to write
arbitrary files to any location by feeding pandoc a specially crafted
URL in an image element. The vulnerability is serious for anyone
using pandoc to process untrusted input. The vulnerability does
not affect pandoc when run with the `--sandbox` flag.
This commit introduces support for the Intense Quote in Docx Conversion.
Previously this was converted to a regular paragraph, but Intense Quote
should be interpreted as a Quote in conversion.
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.
John MacFarlane