aboutsummaryrefslogtreecommitdiff
path: root/source/ss/setup_native
diff options
context:
space:
mode:
authorChristian Lohmaier <lohmaier+LibreOffice@googlemail.com>2013-11-21 01:41:17 +0100
committerChristian Lohmaier <lohmaier+LibreOffice@googlemail.com>2013-11-21 04:04:22 +0100
commitc8c40371caa4507a490f8c5ab0961a35848d01c5 (patch)
tree2ebaf81d94ab9e0b855e4d7cb789d91cd68a14ea /source/ss/setup_native
parent7c6025ab17562741ebfd8d8ae2a8c9207b3f000a (diff)
sync with po-templates for 4.2 libreoffice-4-2-branch-point
and force-fix errors using pocheck Change-Id: Ic842792d6ee5fe0fc5d1b41808671f8c3ae34dc6
Diffstat (limited to 'source/ss/setup_native')
-rw-r--r--source/ss/setup_native/source/mac.po3
1 files changed, 3 insertions, 0 deletions
diff --git a/source/ss/setup_native/source/mac.po b/source/ss/setup_native/source/mac.po
index 66bffc459ad..8be9dd3a176 100644
--- a/source/ss/setup_native/source/mac.po
+++ b/source/ss/setup_native/source/mac.po
@@ -31,6 +31,7 @@ msgid "Install"
msgstr ""
#: macinstall.ulf
+#, fuzzy
msgctxt ""
"macinstall.ulf\n"
"AbortLabel\n"
@@ -95,6 +96,7 @@ msgid "Install"
msgstr ""
#: macinstall.ulf
+#, fuzzy
msgctxt ""
"macinstall.ulf\n"
"ListCancelLabel\n"
@@ -119,6 +121,7 @@ msgid "Run the installer again and choose a valid [PRODUCTNAME] [PRODUCTVERSION]
msgstr ""
#: macinstall.ulf
+#, fuzzy
msgctxt ""
"macinstall.ulf\n"
"StartInstallText1\n"
lue='libreoffice-24-2-4'>libreoffice-24-2-4 LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/sw/qa/core/layout/paintfrm.cxx
AgeCommit message (Collapse)Author
2024-10-25sw/qa: use getSwDocShell() when possibleXisco Fauli
Change-Id: Ia2e3dad4e62fb084c3a88564deb137cbcc7728b5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175573 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-10-05Use good old string literals in assertXPath and friendsMike Kaganski
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
2024-06-06loplugin:ostr in sw/qa/coreNoel Grandin
Change-Id: Iaafc85d9b9042769f30c5662dbc9bf8c0e415312 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168487 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-05-31tdf#160984 sw continuous endnotes: fix the endnote continuation separator lenMiklos Vajna
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>
2024-05-24tdf#160984 sw continuous endnotes: fix the endnote separator lengthMiklos Vajna
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
2024-05-23tdf#160984 sw continuous endnotes: fix the endnote separator positionMiklos Vajna
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
2023-11-19Extended loplugin:ostr: swStephan Bergmann
Change-Id: I210f61f6d90776b086b7058fb1a831d235699fb7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159670 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-15tdf#157911 sw floattable: fix inconsistent inferred bottom border on splitMiklos Vajna
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
2023-09-22tdf#154198 sw: fix lost vertical table cell borders for WordTableCell + RTLMiklos Vajna
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>
2023-08-21tdf#156351 sw floattable: fix missing bottom border in master tableMiklos Vajna
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
2023-08-18Related: tdf#156351 sw floattable: fix missing top border in follow tableMiklos Vajna
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