Age | Commit message (Collapse) | Author |
|
Change-Id: Ia2e3dad4e62fb084c3a88564deb137cbcc7728b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175573
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
These are only sent to an external API expecting char*-like strings,
or for comparison. Having every assertXPath having three of _[ou]str
is too much syntactic noise, making the unit tests almost unreadable.
Change-Id: Ic004a36ea75e7bfe0b96f405c40f926a957b51cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174416
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Iaafc85d9b9042769f30c5662dbc9bf8c0e415312
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168487
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See e.g.
<https://bug-attachments.documentfoundation.org/attachment.cgi?id=194455>,
one remaining difference for the Word vs Writer note separator is the
length of the endnote continuation separator: it's body frame width in
Word, shorter in Writer.
Seems this is specific to the endnote continuation separator, i.e.
normal endnote separator, footnote separator and footnote continuation
separator is not affected. Additionally, it's really footnote vs
endnote: if you put footnotes to the end of the document in Word, it
still doesn't make the separator longer.
Fix the problem by extending SwFootnoteContFrame::PaintLine() to handle
this: if in Word compat mode, first note frame is a follow endnote
frame, then paint the longer separator.
The usual render test way via SfxObjectShell::GetPreviewMetaFile() only
works with 1st pages and we want to assert the 2nd page here, so go via
DocumentToGraphicRenderer, similar to how
EPUBExportFilter::CreateMetafiles() does it.
Change-Id: Ia0ba1138070f1a68f62ea6f5a6a85fbe0f76d482
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168263
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
See
<https://bug-attachments.documentfoundation.org/attachment.cgi?id=194324>,
Word has a longer separator line for the foot/endnote than Writer for
this bugdoc.
Writer defaults to 25% of the body frame width in the SwPageFootnoteInfo
ctor, and we don't seem to change that in the DOCX import. Word has a
static 2 inches setting, which is only reduced if it would go outside
the body frame.
Fix the problem by extending SwFootnoteContFrame::PaintLine() in the
DocumentSettingId::CONTINUOUS_ENDNOTES case to do the same.
I searched the OOXML spec and the MS implementer notes, they don't
specify this 2 inches length, but it seems static: the value doesn't
change with the page size. With this, the single-section bugdoc is now
rendered fine.
Change-Id: I3bb23680937580179b8d37c940ea14e0f80fc7f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168009
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
See <https://bugs.documentfoundation.org/attachment.cgi?id=194306>, the
total height of the endnote separator is now correct, but the
distribution of upper space, line width, lower space is still bad, when
compared to Word.
Our model is 2 spacings and a line width, while Word seems to simply
split the amount of available space: 60% goes above the separator and
the rest goes below.
Fix the problem by breaking up the monster expression for the separator
rectangle in SwFootnoteContFrame::PaintLine(), and then the compat +
horizontal case can do the 60% spacing in the Word compat mode.
The width of the separator is still not correct.
Change-Id: Ic065c138041892225b3c1b7d4bd64d4f1c625611
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167990
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I210f61f6d90776b086b7058fb1a831d235699fb7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159670
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
The bugdoc has a split table between page 1 and page 2. The last row of
page 1 has a half bottom border: it starts on the left of the table,
but finishes earlier than the right of the table. This is since commit
08aea5526c75ff4c5385e960bd940f10ffa19cd5 (tdf#156351 sw floattable: fix
missing bottom border in master table, 2023-08-21).
The trouble is that Writer table borders are really at a cell-level (and
not at row or table level), the current partial border happens because
the first row has merged cells and the last row on page 1 doesn't have
merged cells, so the layout can't do a 1:1 mapping between the first row
and last row cells. It's also far from clear if the fixed result should
be no bottom border or a table-width bottom border:
- Word documents can have cell-level borders (where no inferred border
is wanted) and table-level borders (where inferred borders are
wanted), see the tdf#156351 bugdoc for a case where such inferring is
wanted
- In case only cell-level borders are defined, then Word doesn't do such
inferring
Fix the problem by always inferring such borders, because:
- Writer already did this in some cases for a long time, see commit
a4da71fb824f2d4ecc7c01f4deb2865ba52f5f4c (INTEGRATION: CWS fmebugs04
(1.115.46); FILE MERGED 2008/05/13 13:56:19 fme 1.115.46.2: #i9860# Top
border for tables - correction 2008/05/13 13:49:23 fme 1.115.46.1:
#i9860# Top border for tables, 2008-06-06)
- The Word UI creates table borders by default, so the majority of the
DOCX documents also want this inferring
An alternative could be to only do such inferring for Word documents
with a compat flag, but that looks poor, given that Word doesn't always
do such inferring itself, either.
Change-Id: I052e4591e99d066c3109e8ab8b590e97c8aebd36
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159429
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
This went wrong in commit 0dbecd2d2ebe18a262cfab96e105637840b5b7fe (sw:
fix too long inner borders intersecting with outer borders for Word
cells, 2022-01-06), the problem is that in its current form this assumes
that the first cell is on the left and the last cell is on the right,
which is not true for RTL, so only tweak the length of the borders in
the LTR case.
Change-Id: I513af974855496e507134cf156f9ee5a937a46db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157161
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
The problem was that the bugdoc has a split floating table, and the
bottom of the table on the first page was missing its border. The
borders on the second page were correct.
This happens because the cell itself has no bottom border and the layout
did not extra effort to mirror the top table margin at the buttom, like
Word does.
Fix the problem similar to commit
53798fef2cc0b5b0b9706081a4af5ceca964a41b (Related: tdf#156351 sw
floattable: fix missing top border in follow table, 2023-08-18), so we
add a bottom border for master tables at a layout level, similar how a
top border was already added for follow tables.
Given that this kind of worked already in the past (just top borders,
just the 1 row case), do this unconditionally; but if needed this could
be limited to the "Word table cell" case.
Change-Id: Iafdcd90226fdc425be597d36ad97fb69dca5a89a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155884
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
The problem was that in case a table has a table border but no cell
border, then the follow table was missing a top border in case the
follow table had multiple rows.
This was already working for single-row follow tables since commit
a4da71fb824f2d4ecc7c01f4deb2865ba52f5f4c (INTEGRATION: CWS fmebugs04
(1.115.46); FILE MERGED 2008/05/13 13:56:19 fme 1.115.46.2: #i9860# Top
border for tables - correction 2008/05/13 13:49:23 fme 1.115.46.1:
i#9860 Top border for tables, 2008-06-06).
Fix the problem by checking for the case when the first row in a follow
table has no own bottom border and then take that bottom border from the
last row instead, if that has a bottom border.
The reported case around the missing bottom border in the master table
still needs work.
Change-Id: Ib418da99067a42efcf3bd0e2d6a9467797de619a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155824
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|