The xml.sax.Parser service already existed, it just did not have
a new-style service to create it.
Change-Id: I6f145a7504ff9e149c802f723991954a2801cbc9
the intent of this header has canged over time. now it is already
systematically included with ustring.hxx and the operator overload it
provide fit nicely there...
Just to be safe, since that include as been added to the api during the
3.5 timeframe and therefore is already in 'production'
the header remain and simply attempt to include ustring.hxx
but a warning is issued indicating that this header should not be used
anymore... in a couple of major release we will thenr emove it completely
All internal users of that header are converted.
Change-Id: I8934c55f089e29d78c0f5649b7c87b2ecf024bad
Reviewed-on: https://gerrit.libreoffice.org/634
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
It has been imported as an alien attribute since CWS impressodf12
5b364c2e8baf9b1f6bbe611c0fd6895a88056afc, and could not be written
to a document created from scratch anyway.
Change-Id: I054fcf71d7ddc3ed19735b8aa898d1b1a12db5b9
This attribute is mandatory; for the given bugdoc various
svg:viewBox="0 0 2500 1" are now written.
Change-Id: I7ea2294e0796546dcbb245993c01c2dd2b2a755a
XMLTextParagraphExport: Add a mapping that generates names for those
field marks that don't have a name so validators don't complain.
(regression from 7a1c5e54afe4e4ef7e17c2e9c969cd41221edc28)
There is still the problem that we cannot easily guarantee that the
names (generated or from some field param) do not clash with the names
of actual bookmarks...
Change-Id: I9ed65b94b3e8f725db4354222f2565176b32be52
Create a merged XSAXDocumentBuilder2 interface for this service to implement.
Which is backwards-compatible, but does not require creating a new service.
Change-Id: Iaa96031a0b7c27e957d2edb0394e5eeaaa84cdca
Also checked the following with bin/find-german-comments (all
false positives):
- sysui
- xml2cmp
- udm
- ucb
Change-Id: I2c72f973f5cecf56d70b5419e56338170dd55a2e
The invalidation introduced in 7f9928bfa561ccb6ed4e2baacc7d6960bc1ce231
is unfortunately in the wrong place; the pAllFoo actually point at
vector elements, and so they must not be dereferenced after new elements
are added to the vector, so move the invalidation up a bit.
Change-Id: I244d1d5cfd40469ff6d2c081e057355460d34cf4
PageMasterImportPropMapper: in the case of a single "fo:border"
and "style:border-line-width" attribute, it is possible that the border
is imported wrongly, like this:
1. pAllBorderProperty is set from the imported value, with name "TopBorder"
2. individual pNewBorder[i] are created as copies from pAllBorderProperty,
one of which also with name "TopBorder"
3. pNewBorder[i] is updated with widths from pBorderWidths[i]
4. the individual pNewBorder[i] are added to the property vector
5. the property vector is sorted by property name
6. the properites are applied in order; if the pNewBorder[TOP]
happens to precede the pAllBorderProperty (which is indeterminate
as they both have name "TopBorder"), then the pAllBorderProperty
will overwrite the border widths computed in step 3.
Thus, nerf the various pAllFoo properties so they do not override
the individual Foo properties later on.
Change-Id: I87755f1184d59da2aa72ac053e6f77d7295d6958
If it's named nLast, then it's supposed to point to the last character,
which, with an empty string, logically means it should point before
the start of the string.
Change-Id: I248fbe80c1c4b1c2c8d39f0bcf772f9b85415e4a
