László Németh
5da16bdc79
To solve the trade-off between better spacing and less hyphenation, support hyphenation level and its user interface, the hyphenation slider, like DTP software do. Add new paragraph property com::sun::star::text::ParaHyphenationLevel The hyphenation slider is the basic interface of DTP software to adjust single (or all) paragraphs using better word spacing (i.e. more hyphenation) or less hyphenation (i.e. worse word spacing). It allows 1) to choose the best from the near equally good layouts and 2) to solve an extreme bad layout (caused by words without hyphenation or other corner cases). – 50% hyphenation level means disabled hyphenation, if minimum and maximum word spacing settings allow to break the line within words (default interoperability value). – 100% hyphenation level means using extra hyphenation only if that results better word spacing in the line, than breaking within words. – Between 50% and 100% hyphenation level, use extra hyphenation only if its weighted word spacing is better, than breaking the line between words (weighting grows with the hyphenation level). – Between 0% and 50% hyphenation level it means disabled hyphenation with increased desired and maximum word spacing, depending on the hyphenation level. At %0, the desired word spacing is enlarged to the original maximum word spacing, while maximum word spacing is enlarged by a single space. For example, the original 4-page unit test document with the default 50% hyphenation level contains 14 hyphenations. 100% hyphenation level results in 22 hyphenations, while 0% only results in 8 hyphenations. – sw/qa/extras/layout/data/tdf167648_minimum.fodt, sw/qa/extras/layout/data/tdf169168_minimum.fodt: set maximum word-spacing to 100% from 101% to limit the original unit test only for minimum letter spacing. More information: LO/COOL Book & Typography projects: https://www.numbertext.org/typography/ https://www.numbertext.org/book/ Follow-up to commitcf104be5cb"tdf#119908 tdf#166113 cool#15973 sw smart justify: fix DOCX hyphenation", commitd572576dd6"tdf#119908 cool#15973 sw smart justify: fix "smart" hyphenation", commit529755f091"tdf#166113 sw smart justify: adjust algorithm for interoperability" and commit7d08767b89"tdf#130088 tdf#119908 smart justify: fix DOCX line count + compat opt." Change-Id: I84b3893ea6c5cd4eff74a73514722285e7071392 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207545 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: Jenkins
Schemas for Validating ODF Files
Schemas that can be used for validating ODF files
subdirs:
mathml2: W3C MathML 2.0 XML Schema (needed for Math embedded objects)odf1.0,odf1.1,odf1.2: official OASIS RelaxNG schemasodf1.3: current OASIS draft ODF 1.3 RelaxNG schemalibreoffice: draft ODF schema, with additional LO extensions
The extension schema in libreoffice/ is used by all unit tests if
--with-export-validation is given, which is the default.
Notably this means that if you add a new feature to the ODF filters and you add the required unit test for the new feature, then most likely the test will fail with a complaint from the validator; in this case the schema needs to be updated to contain the new elements and attributes.
The extension schema uses the RelaxNG "include" feature to refer to the ODF
schema; this means that it only contains those parts of the schema that
actually need to be changed - this works well in many cases because the ODF
schema is quite well structured with many named patterns, but unfortunately
there are a few places where that isn't the case and large chunks needed to be
copied to override them.
In the easy case, to add an attribute you just want to search for the
corresponding element, which will have a "foo-attlist" named pattern, and then
add another attribute like this:
<rng:define name="draw-enhanced-geometry-attlist" combine="interleave"> rng:optional <rng:attribute name="drawooo:sub-view-size"> <rng:ref name="string"/> </rng:attribute> </rng:optional> </rng:define>
Currently only the features that are actually exported in the unit tests have been added to the schema; there is still some work to do here to add everything; the crashtesting script also does ODF validation of all files and now also uses the custom schema.
Unfortunately it turned out that there are a lot of extensions already for which no proposal exists [1], and in many cases not even an entry on the Wiki [2], so clearly something like this extension schema is needed.
[1] git grep TODO schema/libreoffice