This is somewhat similar to commit
1acf8e3cfa (sw fields: add Title uno
property, 2022-03-24), except that this is for images, and images
already had a Title, which is persisted to ODT.
So add a new Tooltip property which has priority over the tooltip
generated for URLs, in case the tooltip is non-empty. This helps in case
the URL is long / non-readable / confusing and a more helpful
popup text can be provided instead.
Change-Id: Ife34dab5e4490eb1682c55fb7c01f7509d0057fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132361
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
All places that were previously emitting
`AccessibleTableModelChangeType::INSERT`
and `AccessibleTableModelChangeType::DELETE`
events have been ported to emit
the 4 new event types introduced in
Change-Id I30821a5acafa4f3d1dafdfc219f3b4568d9a6e89,
"a11y: Add new table model change types for row/col insertion/del"
instead.
Therefore, the handling of those events can be
dropped from the gtk3 VCL plugin and for macOS's
a11y listener as well.
Also, drop the now completely unused
constants from the IDL file as mentioned
in Change-Id I30821a5acafa4f3d1dafdfc219f3b4568d9a6e89:
> From a UNO API perspective, this change
> and the final removal of the
> `AccessibleTableModelChangeType::DELETE`
> and `AccessibleTableModelChangeType::INSERT`
> constants in a follow-up commit
> should be unproblematic, because the
> corresponding APIs have been unpublished in
>
> commit 70626249cd
> Date: Thu Nov 29 00:27:03 2012 +0100
>
> API CHANGE a11y unpublishing and add/removeListener rename.
Change-Id: I1c062e26481b916af882e301c5f911aba9550ea3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132221
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
So far, there were two types/constants
to use in an `AcessibleTableModelChange` event to indicate
the insertion or deletion of rows and/or columns. From
`offapi/com/sun/star/accessibility/AccessibleTableModelChangeType.idl`:
> /** One or more rows and/or columns have been inserted.
>
> <p>Use the fields of the AccessibleTableModelChange
> structure to determine the indices of the rows and/or columns that
> have been inserted.</p>
> */
> const short INSERT = 1;
>
> /** One or more rows and/or columns have been deleted.
>
> <p>The affected area of the table is stored in the fields of the
> AccessibleTableModelChange structure.</p>
> */
> const short DELETE = 2;
From the documentation, it would be possible to indicate an
insertion or deletion of both, rows and columns in a single
event. However, there is no single instance where this is
actually used to indicate the deletion/insertion of
both, whole rows and whole columns at the same time.
The way that indices are currently used is rather confusing
and results in incorrect a11y events being sent on maOS as well
as the gtk3 VCL plugin:
When only rows are inserted, row indices are set as expected
(index of the first and last inserted row), but the column
indices are set to the first and last column in the table;
i.e. the indices actually give the range of the newly
inserted cell range, rather than just the indices of the rows
that have been inserted. (The same applies
the other way around when only columns are inserted.)
That's not what I would have expected when reading the
documentation. ("Use the fields of the AccessibleTableModelChange
structure to determine the indices of the rows and/or columns that
have been inserted.")
In the same way, the range of deleted cells is set
when emitting `AccessibleTableModelChangeType::DELETE` events.
In this case, this can be seen as matching what the
documentation says. ("The affected area of the table is
stored in the fields of the AccessibleTableModelChange
structure.")
In any case, the way that the events are handled
in the gtk3 VCL plugin and for macOS results in
the emission of incorrect events,
since those are handling such indices as if both,
rows and columns had been inserted/deleted.
Example for the gtk3 VCL plugin:
Row with index 1 has been deleted from a table.
-> an AccessibleTableModelChange event is sent with
Type=AccessibleTableModelChangeType::DELETE
FirstRow=1
LastRow=1
FirstColumn=0
LastColumn=<index of last column>
This would then result in 2 AT-SPI events being
emitted by the gtk3 VCL plugin:
* one that indicates that row 1 has been deleted (OK)
* another event that indicates that all columns have been
deleted (NOT OK)
Instead of changing the handling of the existing
`AccessibleTableModelChangeType`s, introduce 4 new
types to replace the existing ones that
don't mix handling of rows and columns at
the same time: one for row insertion,
one for column insertion, one for row deletion,
one for column deletion.
This commit also adds handling for the newly added
change types for macOS and the gtk3 VCL plugin on
Linux.
winaccessibility is unaffected because
it doesn't have any handling specific
to the change type.
The qt5/qt6 VCL plugins don't yet have any
handling for the `AcessibleTableModelChange`
event yet (but that will be added in a follow-up
commit).
Existing uses of
`AccessibleTableModelChangeType::INSERT` and
`AccessibleTableModelChangeType::DELETE` will
be migrated to use the new types in
follow-up commits.
From a UNO API perspective, this change
and the final removal of the
`AccessibleTableModelChangeType::DELETE`
and `AccessibleTableModelChangeType::INSERT`
constants in a follow-up commit
should be unproblematic, because the
corresponding APIs have been unpublished in
commit 70626249cd
Date: Thu Nov 29 00:27:03 2012 +0100
API CHANGE a11y unpublishing and add/removeListener rename.
The following Python script was used in follow-up
commits to check that AT-SPI events with the expected
indices are retrieved with the gtk3 VCL plugin after
porting existing uses of
`AccessibleTableModelChangeType::INSERT` and
`AccessibleTableModelChangeType::DELETE`.
#!/usr/bin/python3
import pyatspi
def listener(e):
try:
if e.host_application.name != 'soffice':
return
except:
return
print(e)
pyatspi.Registry.registerEventListener(listener, "object:row-inserted", "object:column-inserted", "object:column-deleted", "object:row-deleted")
pyatspi.Registry.start()
Change-Id: I30821a5acafa4f3d1dafdfc219f3b4568d9a6e89
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132217
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The use-case is user fields, which are kind of variables in the
document. They have a name and a value, but the name might be only
readable to an extension or macro, not to the user. In this case, it
makes sense to have a way to specify a user-readable tooltip.
Be consistent with TextFrames which already have a Title property.
Change-Id: I986792f5e55e0b96489347be482d640d155113cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132077
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
The fix tries to make rendering similar to MS Office.
The ODF standard follows closely the extrusion in RTF and MS binary
format. Rendering uses the 3D scene engine.
The main problem was, that the z-component of the direction was
interpreted with opposite sign. As result the maximum of a light was at
false position. Especially a direction from the observer to the object
has produced a light behind the shape and so looks as if light was off.
The wrong z-direction has produced lighting, which was less intensive
than in MS Office. To compensate that, a third light source was added
as workaround. That part is removed.
Second problem was wrong use of 3D-scene D3DMaterialSpecularIntensity
and D3DMaterialSpecular (= UI Specular color). That was not only wrong
in OOo but in my previous patch too.
D3DMaterialSpecularIntensity corresponds to MS property 'c3DShininess'.
Relationship is Intensity = 2^c3DShininess.
D3DMaterialSpecular is calculated from MS property c3DSpecularAmt and
and c3DKeyIntensity. The light source was missing, but needs to be
included, because c3DSpecularAmt is 'the ratio of incident to specular
light that is reflected on a shape'.
The old unit tests are adapted to this change.
MS gives no information how it softens a light in case of harsh=false.
ODF specifies it as 'implementation-defined'. The patch uses four
additional lights, which have directions in 60° angle to the original
light. The light intensity is distributed. That comes near to rendering
in MS Office. Changing our 3D engine to provide 'soft' lights was not
doable for me.
The way MS Office renders a 'metal' surface is different from ODF
specification. To distinguish the kinds, I have introduced a new
property MetalType. I have discussed it with the ODF TC (see minutes
from 2022-02-07) and got the advise to use namespaced values.
Therefore the datatype is not boolean.
The 'Surface' drop-down in the extrusion bar is changed to make the two
kinds of rendering 'Metal' available to the user.
If a user sets surface 'Metal' in the UI of MS Office, it sets not only
fc3DMetallic but reduces the value of c3DDiffuseAmt in addition. Our
3D-scene engine has the corresponding ODF attribute dr3d:diffuse-color
not implemented. To get a similar rendering I change the material color
of the 3D-objects as workaround.
Change-Id: Ia986b9c318b4c79688e0c0e2d858215b9d612fdc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128449
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
This is a squashed commit containing set of changes:
* Create a input field from sdt text block.
* Advanced support for reading field data from data bindings
which can point to custom xml or properties xml. For this
XOOXMLDocumentPropertiesImporter idl interface was extrended
with extra getterrs to get properties as xml dom elements.
* Support for exporting of this feature back to docx. For this
some extra parameters for sdt block are kept in newly introduced
grabbag for input fields. If field does not contain grabbag it
being exported as before (FILLIN or whatsoever), otherwise
sdt block is counstructed based on data from grabbag.
* Basic support for updating custom xml values back into
custom xmls with usage of xslt transformations. To achieve
this extra parameters were introduced to XXSLTTransformer:
now it is able to support in-memory transformation stylesheets.
Some unittests were corrected: since sdt plain text edit area is
a field located inside paragraph in outout corresponding sdt is
also located inside paragraph (instead of Word's approach with
paragraph inside sdt). Seems this is not critical.
Change-Id: I1a73ef300db3619804f7adf18579bea708764c14
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127015
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Add IsMoved bit to SwRangeRedline, and keep it in both
parts of a split Delete/Insert redline. Set this bit
during DOCX import, fixing incomplete import of
moveFrom/moveTo elements.
Details:
- Search text moving only at redline Insert() and AppendRedline()
instead in the layout code (which was much slower, because
triggered by also mouse hovering):
- detect text moving in Hide Changes mode, too;
- Insertion inside or directly after tracked text moving keeps
"moved text" layout of the original moved text parts (before
and after the insertion).
- at detection of text moving, invalidate (update) layout of the
redline pair, too.
- fix DOCX import: extend makeRedline() with property RedlineMoved
to keep all moveFrom/moveTo stored in DOCX instead of
losing them (joining them with normal redlines) in the case
of missing Delete/Insert pair (see unit test document);
Follow-up to commit ec577f566f
"tdf#145233 sw track changes: show moved text in green color",
commit bcdebc832b
"tdf#104797 DOCX change tracking: handle moveFrom and moveTo"
and commit d32d9a2b3c
"tdf#123460 DOCX track changes: moveFrom completely".
Change-Id: Iaca80e5e326a172bc7ba5fec64b63668b9378e2d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125317
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
No longer does the user get a pop-up dialog when opening
documents that are read-only, asking whether they want to be
notified when the document becomes editable. The change
removes some of the functionality introduced in commit
95eb088802 "tdf#47065 Add new
file open UI options and implement a new thread".
Change-Id: Ic25e8e293e7224fb5086249a9d4814914fa961d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125340
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
To support theme colors the SvxColorItem must be extended with
an optional attribute theme index to define the index to which
theme color current color belongs and an optional tint/shade
attribute define how much the color ha been additionally tinted
or shaded.
[ Miklos: left out the potentially breaking svx/sdi/svxitems.sdi
changes. ]
(cherry picked from commit ccdbf815e00dbe2ba21f7e86b6743df100b7401f,
from the feature/themesupport2 branch)
Change-Id: Ifb0481770be675181dafa94cd2778f374fcf3c7e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125296
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
A document specifies which font each text is supposed to use,
but we still need to map that to a real available font, which
includes also font fallback in case the font selected doesn't
cover all glyphs.
This commit adds API to track this font mapping, first
StartTrackingFontMappingUse() will make VCL record this
information, and then FinishTrackingFontMappingUse() will stop
and return all the information, as a listing saying that
a requested font got mapped to a list of fonts and the number
of times this took place. This can be useful to find out
what actually gets used for a specific document, or compare how
changing fonts available affects a specific document.
Change-Id: I6426ecef354166bef337b1dc9b9007fda148d5c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123051
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
There are no 'XAccessibleSelection::deselectSelectedChild'
and 'XAccessibleSelection::getSelectedChild' methods, so don't
mention them in the documentation for
'getSelectedAccessibleChildCount'.
First, there's 'XAccessibleSelection::getSelectedAccessibleChild',
but not 'XAccessibleSelection::getSelectedChild', so update that
accordingly.
Second, there's no 'XAccessibleSelection::deselectSelectedChild',
and 'XAccessibleSelection::deselectAccessibleChild' doesn't take an
index into the selection, but a child index, s. its documentation
and the commit message of pending Gerrit change
Change-Id: I3c63c647e61baaa6288ffd545d8d89d8b94231de
("gtk3 a11y: Use correct index when deselecting child")
on how the semantics of AT-SPI functions with corresponding
names differ.
(The comment was added in
commit daacf7ed0b
Date: Thu Apr 24 16:35:46 2003 +0000
INTEGRATION: CWS uaa02 (1.1.2); FILE ADDED
2003/04/02 10:06:50 obr 1.1.2.3: #108113# Renamed deselectSelectedAccessibleChild to deselectAccessibleChild
2003/03/14 10:40:52 af 1.1.2.2: #108113# Removed references to the drafts directory.
2003/03/11 15:00:39 af 1.1.2.1: #108113# Moved from drafts/com/sun/star/accessibility.
and
> 2003/04/02 10:06:50 obr 1.1.2.3: #108113# Renamed deselectSelectedAccessibleChild to deselectAccessibleChild
sounds like there might temporarily have existed a draft implementation
that actually took an index into the selection rather than
a child index.)
Change-Id: Ib8eeadd1ffe8e05b87422e3f9d5c4b3fcc6b696d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124332
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Identifiers containing underscores must start with an uppercase letter. (So
that the UNO implementation can use identifiers containing underscores and
starting with a lowercase letter for internal purposes, see e.g. the static_type
member functions in the C++ *.hdl files. idlc checks that with the -cid option,
while unoidl-write silently allows bad identifiers for now, see the TODO in
unoidl/source/sourceprovider-scanner.l, which can be dropped after this change.)
All of the affected identifiers were present since early OOo times, but none of
them appear to be used much, at least not across LO itself, so there is hope
that we can get away with these incompatible changes. (For the constant group
members, we could roll this out in two steps, introducing the new members
alongside the old ones and deprecating the old ones in a first step, then
removing the old, deprecated ones in a second step, so that third-party code
would have more time to adapt. But that would not work for the enum members and
interface methods, so just do all of this in one breaking step.)
udkapi happened to not contain any bad identifiers.
Change-Id: If2d4c16563606f9efb48b937c76af54746377428
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121725
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
It had been present ever since at least 88c437c597
"moved from api" from 2000, but was apparently never implemented nor used at
least in OOo/LO itself. It is problematic as it uses reserved identifiers
("getDisplayLanguage_Default" etc.) that contain underscores and start with a
lowercase letter, and a planned change to unoidl-write will no longer tolerate
usage of such reserved identifiers (see the TODO in
unoidl/source/sourceprovider-scanner.l).
Change-Id: I76a3a3da7b7c1f4c109ca7a12c9f07857ca1be1d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123544
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
... and fix connectivity::firebird::Clob::getSubString.
XClob::getSubString is modelled after JDBC counterpart, that also
takes 1-based position argument. This is also described in multiple
places in our code:
- OPreparedStatement::setClob
in connectivity/source/drivers/firebird/PreparedStatement.cxx
- OSingleSelectQueryComposer::setConditionByColumn
in dbaccess/source/core/api/SingleSelectQueryComposer.cxx
- ORowSetValue::getString
in connectivity/source/commontools/FValue.cxx
However in some places 0-based value was used (fixed here).
To clarify, the mention that the pos argument is 1-based is put
to the corresponding IDL file.
Also the code in connectivity::firebird::Clob::getSubString had
multiple issues:
- no checks of arguments;
- possibility to throw "nPosition out of range" when just-read
segment has enough data;
- wrong start position in case when nPosition is not aligned to
segment boundary.
This change fixes these, and simplifies the implementation.
Change-Id: I119a62dd7f02c9569ce36395ed8cc1a98c931fcf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121884
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Before this fix, date categories imported in oox's DataSourceContext were
stored as formatted strings according to number format code in <c:formatCode>
under the <c:cat> tree. As a result chart2 could not recognize them
as dates. This causes problems like:
* The axis that is linked to date categories cannot use the
scaling/range-selection(min/max)/increments specs mentioned as axis
properties. This results in distorted/unreadable chart renders w.r.t
the date axis.
* No re-formatting is attempted as per the number format provided for axis.
This patch introduces a role qualifer argument to the XDataProvider
interface method createDataSequenceByValueArray to support categories of
date type via this method.
When exporting to oox, write date categories and format code under
<c:cat>
<c:numRef>
<c:numCache>
This patch also fixes some discrepancies in date axis interval
computation (auto mode) found by already existing unit tests.
Change-Id: Ibc53b0a56fdddba80ba452d5567ce98d80460ea7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121525
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
When <c15:showDataLabelsRange> boolean flag is present, the imported
label texts are added as the first text field in oox data label model.
The cell-range associated is also preserved. The export part preserves
the how labels were store originally in <c15:datalabelsRange>.
However in order to make the custom labels reflect the contents of the
cells in the associated cell-range, more work needs to be done. For this
the labels present in <c15:datalabelsRange> needs to be made available
as a data-sequence with a new "role" like "point-labels" in
XInternalDataProvider implementation and and make the label renderer
read this data source rather than consulting the custom label fields
property which is static after import.
Change-Id: Ibc7045fa5ea209d463680c96efb49a06662d2500
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121313
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
...that had been introduced with bbdd3fe352
"INTEGRATION: CWS jl31" ("2006/02/17 14:26:14 jsc 1.1.2.1: #i62141# new script
to prepare some uno type statistics")
Change-Id: I7d738311da73390d29ee1b25e90f58d007cf4cca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120395
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
tdf#64086: fix broken XLSX import of named ranges in charts
Do not create inner data table in Calc for charts, if the
data source contains named ranges. Use the named ranges
(local sheet names and global names) to find the data
source of charts, so it will be updated correctly if we
modify the values in cells.
Second part:
tdf#143623: chart OOXML, offapi: export the named ranges in charts
with the proper special (non-ooxml-standard) Excel syntax.
We need to add "[0]" characters before a global named range
for proper refreshing of chart data. Also we have to add the
sheet name to the local named ranges even if it's on the same
sheet, but only in case of charts. Because of this, add property
RefConventionChartOOXML to com::sun::star::sheet::FormulaParser,
which specifies that use special OOXML chart syntax in case of
OOXML reference convention, when parsing a formula string.
Third part:
tdf#66250 ODF chart: export the reference of named ranges
in case of charts, if the named range contains a valid reference.
Note: maybe export the name of named ranges would be a nicer
solution in the future.
Follow-up of commit 3c76651298
"Related: tdf#64086 Add FormulaGrammar::isRefConventionOOXML()".
Thanks to Eike Rathke for his help.
Change-Id: I10d8563fb436092e833682f331c25b0c0829ef86
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118862
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
Allowed whitespace in ODFF and OOXML are
U+0020 SPACE
U+0009 CHARACTER TABULATION
U+000A LINE FEED
U+000D CARRIAGE RETURN
Line feed and carriage return look a bit funny in the Function Wizard if
part of a function's argument but work. Once a formula is edited, CR are
converted to LF though, probably already in EditEngine, didn't
investigate.
Change-Id: I6278f6be48872e0710a3d74212db391dda249ed2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119635
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
This looks like a copy-paste error.
The *upper* bound is relevant for 'getMaximumValue', the *lower*
bound for 'getMinimumValue'.
Change-Id: Ibe707fde6185c0fa757741683f046393e2003eb8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119600
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Add a method 'getMinimumIncrement' to the XAccessibleValue interface.
The method returns the minimal increment by which the value represented by
the object can be adjusted.
The main motivation is to expose this to AT-SPI, so it can be retrieved e.g.
by libatspi's 'atspi_value_get_minimum_increment' function [1],
s. the note in Change-Id: I8af326c2d24c1801147a56ea2e2a886ab42ac634
"a11y: Expose FormattedField as spinbox" for more details.
The implementation relevant for the 'FormattedField' class is in
'SVTXAccessibleNumericField::getMinimumIncrement', which returns
the spin size.
While at it, also move the comment in sw/source/core/access/acccell.hxx
mentioning what methods are overriden for the 'XAccessibleValue' interface
to the right place.
[1] https://developer.gnome.org/libatspi/stable/libatspi-atspi-value.html#atspi-value-get-minimum-increment
Change-Id: Ie148a4e1cedbdbb5964f8565c81611d3480465cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119596
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The idea is that a bibliography entry (field) can have not only an URL
(which might be unavailable due to lack of network connectivity,
paywall, etc) but also a local copy, which is also a URL.
The local copy doesn't replace the original URL. The local copy is
stored part of the document, since it may be a relative URL, e.g. ODT +
several PDFs copied around in the same directory.
This commit just starts this feature, up to the extent that read and
write of the new property works.
Change-Id: I3c4df2be3a1f3b02a87c097f8a0630951def09d0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119322
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Instead of style:num-prefix and style:num-suffix new list format
is much more flexible for storing list multilevel numberings.
Now it is possible to have not just prefix/suffix but any random
separators between levels, arbitrary levels order, etc.
Internal LO format for list format is changed: instead of placeholders
like %1, %2, etc we right now use %1%, %2%... Reason: for ODT documents,
having more than 9 levels there is ambiguity in "%10": it is "%1"
followed by "0" suffix, or "%10"?
Aux changes:
* removed zero width space hack: since format string is always defined
this hack is interfering with standard list numbers printing
(see changes in ooxmlexport14.cxx, ww8export3.cxx tests)
* changed cross-references values to lists: they are now including full
list label string: previously this was bit self-contradictory (see
changes in odfexport.cxx and check_cross_references.py tests)
Change-Id: I9696cc4846375c5f6222539aeaadbca5ae58ce27
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117156
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
There is zero chance an extension is using this, because it is so
intimately tired together with the oox and writerfilter interactions.
I'm removing this so I can expose the ShapeContextHandler and then
override it's implementation in a more fashion without jumping through
UNO hoops.
Change-Id: I79ef30247f4642303dfdb92bbf8f6e6226234829
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117996
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Miklos Vajna