| Age | Commit message (Collapse) | Author |
|---|
|
in a document containing both of them.
Regression from commit 7dd8f8aace536a8e60e87e61ee1d90d61fba15eb
"tdf#120351 DOCX import: fix slow endnote import".
Change-Id: I0fe764f3b48dd2688afa4b7cf0ee6658737ef9fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119239
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
This is a follow up to commit af99c01570adc0c9205e1650d10866f80bb8118a
to address the review comment.
Change-Id: Iac0a6cf9cb29273229833465cd2d84cdbcc4a3d0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119004
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
In other places, there were caveats for applying a CR
when inserting instead of importing, or when in a header,
but none of those seem to apply in this case.
A section cannot occur in a table, and anytime a
section occurs, it ought to finish off the paragraph.
So a simple clause seems good enough here.
There were basically two different existing unit tests
that match this condition, and neither of them
were currently mis-handled. I safely adapted one of them
to imitate the error condition I was addressing.
Change-Id: Ie8ccd3978276bf10321e0bf80141572f40102874
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118819
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Make it more explicit which list is shared and which list is DOCX-only.
See <https://gerrit.libreoffice.org/c/core/+/118960/3#message-09a4a96aa2d09e2182dac80bb4857a875155fff9>.
Change-Id: I287dfe799eb8597ca0a8ad65ec677d8da79bf1e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118966
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Now it's used in RTF, DOC and DOCX import consistently.
Change-Id: I062a5fbbdf6ee0ef4d3c86a09ce50ac3d588fae5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118960
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
For DOCX, numId means turn off numbering.
RTF probably doesn't have numbering as part of paragraph styles,
so it doesn't need a numId 0 to cancel existing numbering.
This numbering is applied directly to the paragraph during import.
So, for RTF, numId 0 needs to be treated just like any other numId
(except for -1 through -5 although currently
we only import positive numbers).
The statement "if pList and numId > 0" is basically redundant.
pList will not be exist for an invalid numId.
Since numId can be zero for RTF, just get rid of the clause
to avoid any misleading conclusions.
And that is all that this patch is doing. It doesn't really fix
anything, it just changes code that gives out the wrong impression.
AFAICT, RTF never uses styles, and therefore it is always
isNumberingViaRule and so is almost untouched by finishParagraph.
Change-Id: Ibc89d00ce69ad09208254ed85710f1f1aed18074
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118910
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
The current solution has some problems:
(1)
Currently effectExtent is used on import to increase the wrap margins
for fat stroke and effects like shadow and glow in case of contour
wrap.
Problems:
Word writes these values, but actually the wrap polygon is authorative
and third party applications might not write these values at all.
The wrap margins were increased on import, but not decreased on export.
The effectExtent values by Word contain in addition the amount for
rotation as needed in wrapSquare. That part was not removed.
(2)
To avoid negative values in dist* values they were compensated with
effectExtent. For that, the complete effectExtent was shifted to dist*
and effectExtent was set to zero.
Problems:
Contour wrap does not use effectExtent but a wrap polygon. This is set
by Word in a way, that it includes the effect extents. LO uses the
original wrap polygon if available. So moving the effectExtent values
to dist* gives too large 'distance to text' in case of contour wrap,
because effects were considered twice.
The solution here replaces the way, how the margins are calculated in
case of contour wrap. Now the range used by the wrap polygon is
compared with the range used by the shape geometry. The difference is
added to 'distance to text'. To be able to remove these values on
export, they are put into the InteropGrabBag.
LO and Word use different concepts for contour wrap. Any solution gives
only an approximation. But adapting 'distance to text' brings
rendering in LO nearer to the way Word renders contour wrap.
Change-Id: Ic3c1c075fedfa7f79e4fe1f3c095da12cf274e36
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118538
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This really surprised me. On outline numbering, only one style
can use the level of a numbering rule. Any other style that
has it defined is ignored. First come first served.
[All based on experimentation, no documentation found.]
There are two ways the style can be attached.
The highest priority is if the numbering style itself has
a paragraph style defined (which obviously is exclusive).
The second way is just to assign a list level along
with a numbering rule in the para style.
Surprisingly, this too creates an exclusive lock on the level.
These are some existing unit tests that triggered.
I forget which ones are important or valuable,
but none of the contents were affected,
only the UI use of the style didn't apply numbering in Word:
Example1 -ooxmlexport6 fdo74605.docx RT
pStyle not written out for numbering.
List-number-2 gets ilvl0 before List-number-1,
and loses pStyle for absLevel 1
[NOT REALLY A PROBLEM.
That is also how Word sees it. These aren't chapter numbering,
so the pStyle settings just get dropped.]
Example 2 - ooxmlexport7 fdo76979.docx RT:
Bullet gets the numbering, but not Bullet2
Example 3 - ooxmlexport11 tdf101122_noFillForCustomShape.odt RT:
Heading 9 gets the numbering, but not Heading 10
[Typical LO-originating document.]
Example 4 - ooxmlexport13 tdf95848.docx RT:
Heading 1, so not Heading 2
Example 5 - ooxmlexport14 tdf136929_framesOfParagraph.odt RT:
OOoNum123Start, so not the others (who inherit from start anyway)
Change-Id: Ia27131ae6d31b6cff240477f3546ccf92ea69160
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118707
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
like Writer for DOC import and MSO do to avoid to start
endnotes on a new page.
Change-Id: I37d54f189e7aa1f4d0ac829b6af0c03aec64b9f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118541
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
This reverts commit a7eb2f57d8e586577679ecd085b9aa90746ec36b.
Reason for revert: tut tut, appears I was wrong
Change-Id: Ie21db35d7809c2bc3d71c8231bf13bbdc0415b5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118716
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we can elide some null checks
Change-Id: I6fb07daf96b76dfa9223dad64bc9690585c00b2d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118736
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we can avoid some dynamic casting, suggested by jluth
Change-Id: I9895d16c6228e01f802b369f4bdcf1ccc9bf6bfc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118735
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
First of all, the presence of an outlineLevel is not
equivalent to being part of Chapter Numbering.
Plus even if it is a chapter numbering style
it should be fine to write "Outline" as the numStyleName
after all of the prior rework of numbering import.
So lets not keep unnecessary exceptions.
Change-Id: I89149e199eddacefd0971c805e03d3ad66a1672b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118706
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
This seems bizarre. nListId was only set when the style
defined it? What about the directly applied rule?
Surely that has more relevance in all the
subsequent code that used the value in nListId,
as borne out in all of the code that re-calculated nlistId2.
Change-Id: I188e812388c706cf0e785fdede29a6d21be12867
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115260
Tested-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
If direct formatting specifies a numId, but does not provide
a listLevel, the listLevel can be inherited from styles.
Since this is a NOT-OVERWRITE, it is fine to try to
insert again even if direct formatting has already
inserted a level.
Change-Id: Id6e492c8f686949de862cb052866b824ef90d8ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115259
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
and so does numId 0.
Wow - this is REALLY FUNDAMENTAL stuff, and we weren't
handling it? Did anyone look at any of the specs
when they were implementing import of numbering?
Change-Id: I3ea20baccfae34751328558a873ccdcfda0de0a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115258
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Just like numId, listLevel is inherited from parent styles.
This was totally missing. Even the direct formatting of
a listLevel value was ignored (although that case would
be rare, because usually both numId and listLevel are defined
together).
It seems like the most fundamental basics of our numbering
import are wrong. EXTREMELY DANGEROUS TERRITORY,
although this particular change ought to be quite safe.
Change-Id: Ia3cbd941a0a90a932938597e0797ee8e2b0aca6c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115257
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
anchored to characters or paragraphs.
Tracked deletions and insertions weren't imported,
if they contain only images anchored to character,
resulting loss of the document content: i.e. deleted
images were reappeared, as not deleted images.
Note: because change tracking of the OpenDocument
and Writer supports only text range based changes,
the fix is a workaround using zero width spaces
to create an invisible text around the anchoring point
of the images. This workaround is not used, if it's not
necessary, i.e. if the image is part of a bigger
deletion or insertion, which contains also text, not
only an image.
Change-Id: Iaae6aae2c01191512c71117a0c788a4147c4cae0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118557
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
I have found that in both DOC and DOCX numbering bugs,
many can be fixed simply by not assigning Chapter Numbering
at all. So set a minimum threshold to deter useless assignments.
[Note that a LO round-trip should save as numId 1,
and thus a single entry would make it qualify.
For Word-authored documents, this threshold means
at least 3 Heading X styles (which matches LO default workflow)
or 6 out of 9 Levels defined for non-heading styles.]
Change-Id: Ic3d1c800a703721e7ab5302e274ee1eeda496ac0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118543
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Change-Id: I21725931777ff4ce8963db3af345c574645336ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118547
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
The property value was correctly read from wrapTight and wrapThrough
to bContourOutside, but not added to the shape properties.
Change-Id: I825ec2a652031edf69e05f611e6da0f1afd862cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118456
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
This totally up-ends the current way of doing things,
but it was so totally broken, and confused us for a very long time.
Chapter Numbering has nothing to do with "Heading X" styles!!!!!!!!
Thus, we can clean up a lot of nonsense clauses.
The existing code makes it sound like the constraints of
"outline numbering" are an MS format thing, but actually it is
just an implementation detail of how LO contrains styles
and listLevels.
Yes, it is still nice to be able to round-trip the
Chapter Numbering settings, so we won't ignore it completely,
but really, all the complexity comes from trying to cram
the normal flexibility of inheritable, style-assignable
listLevels into a single special-purpose numbering rule.
One thing that has always killed us is that direct formatting
could not share in this unique style. But it needs to in DOCX.
So, the key here is to NAME-ASSOCIATE the "Outline" style,
so that ALL references to that numId end up pointing to the
same rule, even if it is the super-special oddball one.
P.S. Chapter Numbering should have NO IMPACT on the
import process. It should only affect UI interaction
when a user assigns a paragraph style: whether LO can
apply a numbering listLevel or not.
THIS IS EXTREMELY DANGEROUS TERRITORY! WAIT FOR 7.3!
existing unit tests that mapped to a numId other than 1:
ooxmlexport3: tdf95495 - numId 4
ooxmlexport4: tdf81345 - numId 3
ooxmlexport5: tdf123262 - numId 48
ooxmlexport8: fdo74745 - numId 6
ooxmlexport10: tdf89165 - numId 12
ooxmlexport14: tdf133605 - numId 2
ooxmlexport16: tdf132752 - numId 2
and one example which didn't take the first available choice:
ooxmlexport13: tdf95848 - preferred numId 3 over numId 2
Change-Id: I561cd1594f198ad402893c77c1c983f206f53c57
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115614
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
See also commit a2e964afc5187fc1e3b38720ec10ad9856b87020, doing the
same for DOC.
Change-Id: Ib0ddb36de8589f9264fe857b20a6ef2aa2607c52
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118369
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ifa237cde581c9b89956db104db9f87a901f84d72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118306
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
DOCX body text can overlap with header/footer, if top/bottom
page margin is negative. To support this, convert header/footer
text content to textbox anchored to header/footer, if needed.
Note: possible improvements:
1) Skip this hack, if the header is small enough to not overlap with
the body, calculate only the height of the header at the import time.
2) This hack does not fix the case when the top of the header
is under the top of the body. (A problem in DOC import, too.)
This could be achieved by repositioning the dummy header to the top,
and lower the textbox by the same amount. (This would still not
resolve the extreme situation, when the body start from 0 mm
(in LibreOffice, header must be at least 1 mm).
3) Import of VertOrientation::BOTTOM property seems to be bad,
or at least the footer loses this property after a DOCX round-trip,
resulting bad footer position.
4) after a round-trip, the 1 mm height of the dummy header
increases to 1 line height. Also the "Autofit height" and
"Use dynamic spacing" settings are changed, likely related
to their missing DOCX export.
Co-authored-by: Tibor Nagy (NISZ)
Change-Id: I8319c93c6c5a980878ee9956c8ab2953da60409e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117842
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I3ff5333c1e73ca61b0a7339e4b7dcfce211b88e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118207
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we only compile it once, shaves 1% off load time
Change-Id: I8e6e20205659582901ffb8d4496ce44906146204
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118157
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic943746614b894690768d0d6109123c1af819c52
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118081
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
|
|
.. in a document.
Shavves 20% off my load time.
Change-Id: I8101b4d229485ebdef0c1f72f856e7cda43559d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118045
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
Change-Id: If73e9183dbf6e53291da0348a1ea112d0c669669
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118012
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
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>
|
|
Change-Id: I333100fda7e181f68f36b03279b3fbb8cb768310
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117615
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
LO uses the bounding box of the shape in case of type 'Parallel'. Word
uses in the corresponding wrap 'square' a box based on the full size
of the shape. That will be very different in some cases, e.g. for an
arc. And Word exchanges width and height in case of rotation angle in
[45°;135°[ and [225°; 315°[. To get the same appearance as in Word,
the wrap margins are suitable expanded on import.
Word puts the additional space needed for fat strokes into effectExtent
in case of wrap 'inline', so there is no need to add the half strokes
width in addition. Word determines the area for the shape depending
on rotation angle. Both are now considered. Total same appearance is
not possible because it would need negative vertical wrap margins,
which are currently faulty in LO, see tdf#141880.
Patch solves in addition tdf#142486, tdf#142305
The export to Word would require negative values in effectExtent in
some cases. They are allowed in OOXML but not supported in Word. My
idea is to switch to wrap mode 'Tight' if needed. But export of wrap
has so many bad parts, that it needs separate work and is not
included here.
Handling of border width for export of own frames is missing.
Unittest changes
----------------
testDmlTextshapeB and TestDmlTextshape in ooxmlexport6.cxx are set to
current values. Import and Export still have large errors with these
shapes and correct value from file is unknown. So an exact value is
pointless. Only the original problem needs to be still fixed, which
is the case.
testWpsOnly in ooxmlexport10.cxx. I have removed the test for
LeftMargin equals 0. The test makes no sense, because the original
file has distL=114300.
testTdf124600 in ooxmlimport2.cxx.
I have added a tolerance. It would fail with Expected: 2029,
Actual:2028, likely a rounding problem somewhere.
testTdf124600 in ooxmlimport2.cxx
Word refers to outer edge of the border for align='left', LO aligns
at snap rectangle. The different intepretations become visible if a
thick line is used. LO needs a margin to get the same rendering as in
Word. So an expected value of 0 is wrong and I have disabled the test
for now. ToDo: tdf#142798. Get the correct margin and activate the
test then.
testTextframeGradient in ooxmlexport2.cxx. I didn't find any reference
for a default value. The test is not reliable, I get both 316 and 318
as actual value. Handling of shadow in VML shapes is buggy, the values
for margin and shadow are wrong anyway. Reports are e.g. tdf#142486,
tdf#142558. For now I have added a tolerance of 2.
testDMLGroupShapeChildPosition in ooxmlexport6.cxx. The accuracy has
become better. After reload we get the same values as before.
testEffectExtent in ooxmlexport.cxx. tdf#142805. I have disabled the
test, because the image is not loaded at all, and therefore it makes
no sense to test a margin of it. And you can only test the sum of
distL and effectExtent l, because LO has only one property
'LeftMargin' for it.
testEffectExtentInline in ooxmlexport.cxx. To get the same vertical
alignment as in Word, it would be necessary to have negative margins,
but those are not implemented yet. tdf#141880. Currently the patch
contains a heuristic to detect unchanged objects and write the
grab-Bag values then.
testEffectExtentLineWidth in ooxmlexport16.cxx. I have changed the
expected value from 508 to 506. That is still away from the to be
fixed faulty 561. It is a VML shape and import of connectors in
VML shapes is faulty.
testRelorientation in ooxmlexport4.cxx. Changed to 8662, the original
problem is still fixed. I don't know the reason for the difference to
the values from file.
Change-Id: I28f156637f6ae64975cf2917f0e5cc89e689aff5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115668
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
for faster lookup.
Shaves 3% off my loading time
Change-Id: I075b42db52914988be4adef303825c211b02353f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117848
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
I cross-checked with what was imported via DOCX
and took inspiration from tdf#141341 to consolidate
these two nearly-identical functions that otherwise
would need to be kept in sync (and never are)..
Change-Id: I7e021d7c9d68597da5b0ce1311ae243fc003e4f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117736
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
so we don't have to scan the list repeatedly, which is O(n^2)
This takes my load time from 37s to 22s
Change-Id: I0df2f2ace82f5cd6287c7ded796b02c5242269ec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117396
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See tdf#42949 for motivation.
Change-Id: I559eb3b41a5a0fdb37db6c45d73211ca223384fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117193
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I1bd31fe6cf0f8aaf4f2cfe1d3d49e61a0633f361
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117057
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ib64799f06ee1fbcc43132df6ad44975a0dff347e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116973
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This really confused me because it lead me to think
that this was something done for MS compatibility.
Well, that is only true in an off-handed way.
LibreOffice itself was changed to work similarly
to MS Word. So there is nothing special about how DOC
or DOCX/RTF are handled.
Since the compat settings are not saved or loaded
into MS Formats (i.e. it just takes the default value),
and since on an ODT save it also will just save
with the proper default value, there is no need
to specify "TabOverflow = true" in non-ODT import filters.
Only ooxmlexport16 has a unit test that reacts if
tabOverflow is false. That one is mine and it indicates
that the document would be better if tabOverflow was off,
so there are no examples of how tabOverflow improves a doc.
Change-Id: I97c25154108bc1ca0fcd3dfcff66fea0ea2bca7e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116741
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Change-Id: I3539edf26a793f89d38f3df376002f4ed4295343
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116869
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
DOCX in 2013 (compatibilityMode 15) no longer supports
TabOverMargin (i.e. the text margin),
but it does a similar kind of thing if the tab goes
into the spacing-after of a paragraph.
So add a compat flag to handle this in-between
kind of situation.
I grepped -i "tab_*over_*margin" to see if I was missing
anything. Decimal/Center proved to be only tabOverMargin.
IsInSect shouldn't matter since it fits inside the printing range.
The other places where I didn't insert TabOverSpacing
didn't seem relevant based on a code read.
Tab-after-tab still doesn't work great, but what we have is
already a massive house of cards that will just collapse if changed.
No real provision for handling tabs-over-paragraph-end.
-auto-tabs are created instead of "beyond nMyRight" tab,
unless it is the first tab defined.
-doesn't allow auto-tabs to fill the remaining space.
But on the other hand, MS Word's implementation of tabs
follows some kind of incomprehensible bizarre logic,
so just ignore the tabs completely, please.
Change-Id: I3723107b29ec3e287ea8661544711c13eee3ca48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116667
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
When compatibilityMode is 15, TabOverMargin no longer
seems to apply. This is a dramatic visual change in docx
that I didn't find any documentation about,
but the visual change is obvious enough proof.
LibreOffice started saving DOCX as c15 mode in 7.0.
[P.S. related TabOverflow also seems to be false with c15,
but it acts differently than what LO's tabOverflow
code does. That was discussed in a different patch
and seems to be a dead end, so I'm ignoring that aspect.
Way too many complications and effects on LO native mode.]
Change-Id: I5a0a6d695d6825444cf6a362a81803f306e6c6e3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116337
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
The RTF spec says \'hh is the expected form, where both "h" are 0-9, a-f
or A-F. But Word accepts the bugdoc, so don't reject this input, handle
\'<number><junk> as \'0<number>.
At least the current case ignores the actual value, as it's a single
character to provide a non-unicode value after \uN for old readers that
don't support Unicode.
Change-Id: Ib61247ab08278ca5012cc887cee26c7571c29fc6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116499
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Since LO 7.0 commit cad788328ec6ef4b3071cf9002dfac12347562da
allowed bullets in the outline, I think you also want to be able
to set the character style, wouldn't you?
In any case, isOutlineNumbering is basically a meaningless
and inaccurate concept anyway, so just get rid of that
ancient clause.
Change-Id: I2e40a3749b4a18864585c309349ea0e4ba73a9da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115613
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Change-Id: I9a4ba6b6369da0bac489718230880b04912bd1d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116214
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
There were multiple problems here:
- commit 8f1a1092d47947847e1d888b0284e8364c663d1f (tdf#97371 DOCX
import: fix text covered by shape, 2016-01-28) disabled to-char
anchoring for TEXT_LINE (e.g. "alignment top, relative to line") because
changing the anchor type of a TextBox could not be changed, but this has
been implemented in sw/ in the meantime, so it can be dropped
- Now that the anchor type is to-char, we can set the vertical relation
to TEXT_LINE, but Word's positive value is "below line", and ours mean
"towards the top of the page, from the bottom of the line", so we need
to drop the workaround of commit
3303a4c5f21874453e634d84408c50e7a0055a4d (tdf#135153 DOCX import: avoid
line-of-text relation with to-para anchoring, 2021-01-18)
Once these are in place, we can fix the remaining problem by inverting
the vertical position of the shape, which instantly fixes the
overlapping textboxes in the bugdoc.
Change-Id: I895abb76d3bd3bbe3a84e5c27a77df722b96226a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116182
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
As far as I see, Word is using lists with id=0 and no list definitions
to reset list numbering used in this paragraph. At the same time Word
is still using some of default list properties. For example in this
scenario parent style has defined first line indent, but in paragrath
it is overwritten by "not existing" list=0 without definitions.
To this moment I know about only first line indent behavior, but
probably some other properties are also affected.
Change-Id: I344c907bb7a7b83a91f5727e13ad184fb44137b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115795
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
Change-Id: I1608e03ff9f6fbc55987010e88897e034b690b3a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115552
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
