| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Change-Id: I63eeb8662ee28f1a0e990160b1ff9992d9d9337f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166111
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Support XSL attribute "column" and CSS 4 attribute "spread",
stored in loext:hyphenation-keep-type, to give better control
over hyphenation-keep. E.g. spread: both parts of a hyphenated
word shall lie within a single spread, i.e. when the next page
is not visible at the same time (e.g. the next page is not a
right page of a book).
– css::style::ParaHyphenationKeep is a boolean property now,
importing hyphenation-keep = "page" as true.
– type of ParaHyphenationKeep, including the new non-ODF types
is stored in the new ParagraphProperties::ParaHyphenationKeepType.
– default value of ParaHyphenationKeepType is COLUMN for
interoperability.
– Add checkboxes to Text Flow -> Hyphenation Across in
paragraph dialog:
* Column (previously: Hyphenate across column and page)
* Page
* Spread
– enabling/disabling them follows XSL/CSS 4/loext, i.e.
possible combinations:
* No Hyphenation across
(hyphenation-keep = "page" and loext:hyphenation-keep-type = "column")
* Hyphenation across [x] Column
(hyphenation-keep = "page" and loext:hyphenation-keep-type = "page")
* Hyphenation across [x] Column [x] Page
(hyphenation-keep = "page" and loext:hyphenation-keep-type = "spread")
* Hyphenation across [x] Column [x] Page [x] Spread
(hyphenation-keep = "auto")
– Add ODF import/export
– Update DOCX import
– Add ODF unit tests
Note: recent implementation depends on widow settings: disabling widow
handling allows hyphenation across columns and pages not only in table
cells.
Note: RTF import-only, but not used bPageEnd has been renamed to bKeep.
Depending on the RTF test results, likely it will need to disable
the layout change, e.g. GetKeepType()=ParagraphHyphenationKeepType::AUTO,
if PageEnd uses obsolete hyphenation rule, i.e. shifting only the
hyphenated word to the next page, not the full line.
More information:
– COLUMN (standard XSL value, defined in
https://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#hyphenation-keep)
– SPREAD and ALWAYS (CSS 4 values of hyphenate-limit-last,
equivalent of hyphenation-keep, defined in
https://www.w3.org/TR/css-text-4/#hyphenate-line-limits).
Follow-up to commit 9574a62add8e4901405e12117e75c86c2d2c2f21
"tdf#132599 cui offapi sw xmloff: implement hyphenate-keep" and
commit c8ee0e8f581b8a6e41b1a6b8aa4d40b442c1d463
"tdf160518 DOCX: import hyphenation-keep to fix layout".
Change-Id: I3ac6d9e86d0ed1646f105de8607c0e8ebc534eaa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165954
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Regression from commit 6d8da2b2deb4be2182ca1852cec7eb38a4c654eb
(tdf#96943 sw Hide Whitespace: don't create pages for widow / orphan
..., 2016-01-07), the reduced bugdoc has 3 paragraphs, 1.5 paragraphs
are on page 1, 1.5 paragraphs are on page 2. Hiding whitespace moves the
entire paragraph 2 to page 1, which is unexpected.
Checking the original use-case, the
CheckPageHeightValidForHideWhitespace() call in
SwTextFrameBreak::IsInside() can be removed, and still the original
"type character at the end of the document results in a new, unwanted
page" problem is not back. Likely at some point in the meantime we gave
up on these reduced page heights for the last page, so the original
tweak for widow/orphan lines is not needed anymore.
Fix the problem reverting the original, no longer needed fix, but
keeping its testTdf96943 test in the CppunitTest_sw_uiwriter4 suite.
Such reducing of last page doesn't happen with Word 2021, so probably
this change in behavior is wanted.
Change-Id: I5d46d0cd84d0071ffb9ef3f8e4ca7335e61bb226
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164408
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Both parts of a hyphenated word shall lie within a single
page with ODF paragraph setting fo:hyphenation-keep="page".
The implementation follows the default page layout of
MSO 2016 and newer by shifting the bottom hyphenated line
to the next page (and to the next column, see last note).
Note: this is a MSO DOCX interoperability feature, used
also in DTP software, XSL and CSS.
* Add checkbox/combobox to Text Flow in paragraph dialog
* Store property in paragraph model (com::sun::star::style::ParagraphProperties::ParaHyphenationKeep)
* Add ODF import/export
* Add ODF unit tests
New constants of com::sun::star::text::ParagraphHyphenationKeepType,
containing ODF AUTO and PAGE (borrowed from XSL), and for the
planned extension ParaHyphenationKeepType of ParagraphProperties:
– COLUMN (standard XSL value, defined in
https://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#hyphenation-keep)
– SPREAD and ALWAYS (CSS 4 values of hyphenate-limit-last,
equivalent of hyphenation-keep, defined in
https://www.w3.org/TR/css-text-4/#hyphenate-line-limits).
Note: the implementation truncates only a single hyphenated
line, like MSO does: the pages can end in hyphenated
lines (i.e. in the case of consecutive hyphenated lines),
but less often, than before.
Clean-up hyphenation dialog by collecting "Don't hyphenate"
options at the end of the hyphenation settings, and negating them
(similar to MSO and DTP), adding also the new option
"Hyphenate across column and page":
[x] Hyphenate words in CAPS
[x] Hyphenate last word
[x] Hyphenate across column and page
Note: ODF fo:hyphenation-keep has got only "auto" and
"page" attributes, while XSL defines also "column".
Because of the interoperability with MSO and DTP,
fo:hyphenation-keep="page" is interpreted as
XSL "column", avoiding hyphenation at the end
of column, not only at the end of page.
Change-Id: I5c6b7adc0671a5a790568e7bf1d33256e607f85f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164158
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
The problem is that the check if the line contains a non-fly portion
was only done in the loop, but the first line is already handled before
the loop, so its non-fly portions are ignored and never less than 2
lines are moved, regardless of widow/orphan settings.
(regression from commit 8c32cc17ce914188ea6783b0f79e19c5ddbf0b8d)
Change-Id: Ic017a17233fcd58e22d54386650328f00fb3e9f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156121
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
SwTextFrameBreak::IsInside() may be called in different situations,
during formatting it should be possible to move the footnotes, but when
called from SwTextFrame::CalcPreps() this is problematic as it does not
format the lines, it iterates over existing lines.
The problem is that the footnote frame is moved to the follow's page,
but the footnote portion remains on the master, and then the follow is
joined while the footnote frame's mpReference still points to it.
(regression from commit 391613785ae6fbb735cf7a86ea2f6a93161a8769)
Change-Id: I4290dcd242a7f5292ad4f50c1407c9cd88e80a6a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154557
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
The bugdoc has 3 floating tables on page 1, and the anchor of the last
floating table goes to page 2. All anchors are empty (no text), apart
from serving as an anchor for the floating tables. The last floating
table goes to page 2 in Writer, but not in Word.
The problem is quite similar to what commit
2d0a4ef1d83b8de6cb133970c2c35ae706fb058e (sw floattable: fix negative
vertical offset handling on page boundary, 2023-06-20) fixed already,
but here the anchor of the floating table is empty, and there it had
some text, which is a different codepath.
Fix the problem by first requesting a frame split in
SwTextFrame::FormatAdjust() even for empty paragraphs with flys (so the
fly part can go to page 1 and the empty paragraph can go to page 2) and
second disabling the SwTextFrame::FormatEmpty() optimization that would
assume no split is needed, while a split is required for a correct
layout here.
With this, the DOCX version of the original bnc#816603 document finally
renders without overlaps (4 pages, 11 floating tables).
Change-Id: Ie64ce92bf19b3dee8059fa14294d7599b41cc53f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153866
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
The bugdoc has 3 floating tables, the last one was on page 1 in Word,
but it was on page 2 in Writer.
It seems what happens is that the vertical offset of the last table is
negative, so it is moved above the paragraph before the last floating
table, but once the anchor frame (last paragraph) is moved to a new page
(because it doesn't fit), then its fly frame is also moved to page 2,
which leads to overlapping text in the original bugdoc. Interesting this
works already with 0 vertical offset, and in that case we split the last
paragraph, fill the page 1 part with a fly portion and fill the page 2
part with the anchor text.
Fix the problem by:
- triggering a split of the frame in SwTextFrameBreak::IsBreakNow(): if
the anchor frame doesn't fit (has to be moved to a next page), then
split it, so only the anchor text is moved, the fly is not (so its
position matches Word)
- preventing the manipulation of the frame offset in
SwTextFrame::AdjustFollow_(), so no content is moved from the follow
to the parent, because that would mean later we move the joined frame to
the next page
- finally minimizing the frame height at the end of
SwTextFrame::Format(), so the master still fits the current page
An alternative approach would be to extend
SwAnchoredObject::FindAnchorCharFrame(), which already has code to
handle the case when the text frame master and the anchored object is
not on the same page, but that operates on existing anchor frames, and
here the original problem is that the entire anchor frame is moved to
page 2, so we don't have anything left on page 1. Note that this is all
specific to floating tables, I could not reproduce the same behavior
with an anchored shape in Word.
Change-Id: I007b57b369f5c1e98ccad77111958dfd9335f079
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153309
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
GetLineCount was a sal_uInt16 value, that allows only 65535 lines to be
counted. This is changed to sal_Int32 and also the underlying data type
for the lines number is changed from sal_uLong to sal_Int32, but not for
pages number. With this change, the maximum possible line number is now
increased to 2^31-1 = 2,147,483,647.
Change-Id: Ibee2d24e638204133f0ef085564016543f73d351
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143173
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
Change-Id: I6cbdabfe794e37f7e00fa730f672bf8318b86b83
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148549
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
The bugdoc has a single table cell, and widow control is meant to move
the last 2 lines to the second page, but only one page was moved there.
The problem is that widow / orphan control was completely disabled
inside split table rows, but Word does this.
We know when a table comes from a Word document, so in that case enable
widow / orphan control inside split rows as well.
Do this only for in-fly tables for now, doing this in general would need
more work, as pointed out by CppunitTest_sw_layoutwriter's
testForcepoint76. It is an RTF file that doesn't open in Word, but we
would layout-loop on it if this would be enabled in general right now.
Change-Id: Ie37be61443a274f408e1124983d1d495de5636c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148521
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Widow / orphan control in DOCX tables were disabled in commit
8b13da71aedd094de0d351a4bd5ad43fdb4bddde (tdf#128959 DOCX import: fix
missing text lines in tables, 2020-01-28).
That workaround helped with the particular bugdoc, but it also disabled
widow / orphan handling in general, and breaks e.g. orig-nocompat.docx
from tdf#61594, because the second page's last row is meant to contain 6
lines with widow control enabled, but the model has widow control
disabled, so the layout can't work properly.
Fix the problem by improving the layout's WidowsAndOrphans::FindWidows()
to handle conflicting widow / orphan control requirements in a fixed table
row height context, so the writerfilter/ change from the above commit
can be reverted without re-introducing tdf#128959.
An alternative would be to keep the layout unchanged and limit the
writerfilter/ change to fixed height rows, but that still feels like a
(more specific) workaround.
Change-Id: I8378d356e116774275dff337d17b19bd79c84c1c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148456
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Reportedly regression from commit 1cb7e4899b5ada902e99a0c964ee047950c07044
but reverting that on master doesn't seem to help.
Inserting paragraphs with single letters into the first cell on page 2,
once we get to "s" and press Enter, the infinite loop happens as text
frame 56 is split at index 0 (where a fly is anchored), the new follow
moves to page 3, and very quickly frame 56 is formatted again and all
text in the follow moves back to page 2, where it doesn't fit with its
anchored fly.
The problem here is that the (Word format) file sets the
ConsiderObjWrapInfluenceOnObjPos mode, which disables any use of the
SwLayouter::FrameMovedFwdByObjPos() etc. functions.
Oddly enough the spec obj-pos-without-wrapping.sxw claims that in this
mode, "If a paragraph respectively one of the anchor characters moves to
the next page during its format in step (2) or (4), the process is
re-started with this paragraph, the complete paragraph is moved to the
next page and it is assured that the paragraph doesn't move back again."
What happens instead is that when a fly position is changed, its
mbRestartLayoutProcess flag is set.
So let's try to check this flag during SwTextFrame::Format(): stop at a
position where a fly is anchored in a follow frame that has the flag
set, via rInf.SetStop(true).
This is similar to a check in SwFlowFrame::MoveBwd() that prevents a
frame from moving back if it has an anchored fly with this flag set.
Now we get a different loop, where the text frame moves forward, then
back and then splits again.
This is because ShouldBwdMoved() sees that the first line of the text
frame fits into the cell of the previous page - but the first line
consists only of a SwFlyPortion and a SwMarginPortion, for the fly
anchored in the same text frame.
So change WidowsAndOrphans::WouldFit() to continue until the first line
that doesn't consist entirely of flys.
Then there's another loop where the follow flow row is joined and then
splits again - this is very similar to the previous problem, change
SwTextFrame::FirstLineHeight() (which is only called from table code) to
continue until a non-fly line as well.
Unforunately this is all not so clear because we can't actually tell
which text frame contains the anchor of a SwFlyPortion, so let's see
what's going to break with these changes.
Change-Id: Ia6e80f86f6ca3d2e3d91651b6a403c050d74ebfa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141383
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
With the fix it now happens that after SwUndoDelete there is a gap at
the bottom of page 21 and the paragraph at the bottom of it is split
with 2 lines ("(here, wisdom), " etc.) on page 22.
This is because when this SwTextFrame 1927 is formatted, there are next
frames also on the page and those have footnotes on the page.
These footnotes take up space and so SwTextFrameBreak::IsInside()
breaks off the last 2 lines (1 may still fit but it has 2 widorp).
A similar problem was fixed in commit 391613785ae6fbb735cf7a86ea2f6a93161a8769
for footnotes anchored in follow of the current frame, but here
RemoveFootnotes() cannot be used as it requires the next frame to
already have moved to a different footnote boss, which clearly hasn't
happened yet.
So try something similar to commit e37ffdd118da2d21c5e78e8c7b67252d0d1adc8c
and count the space taken by such footnotes as available for the text
frame.
Change-Id: I8f4c1332dc471a68539306a8788a0f59d0b12b1d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131256
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
301278b656e76b6f42af5cf8a6f5c6c02acfffeb and
6fdd0a3f8b3448a9a246496191908c92156cc38b switched
some sal_uInt16 types to sal_uInt32.
Additional commits related to the change:
9e075acf2bf1ce6c43fdf5b601507ee0663bd691 and
2634bc59092b24217d984a5845365d703bdb08d2.
A fallout from this change was tdf#144305, fixed via
0c3e47cc2f0570a7cd8ff4889763991a86b29f26.
Instead of adding further casts to force conversion to signed
to avoid unsigned types underflowing into large positive numbers,
convert these types to signed SwTwips.
Change-Id: Icb7fbae79621d452cd03bb01dc620f60a26f1db0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123014
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
... WidowsAndOrphans
See tdf#94879 for motivation.
Change-Id: I1999c83e5afe100b95481ac470f4d854b5f113f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110547
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I086860cefe9f26c3728fe0d8266c35dae37b9570
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99887
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
When the simplified (thanks Vasily) bugdoc is loaded, it has 2 pages and
the last text frame 6 on page 1 has N lines, but after hiding tracked
changes and showing them again, page 1 has N-1 lines, the last line
starting at offset 1064 moved to the follow frame 7 on page 2, and this
is the only difference from the state after loading.
Frame 6 is formatted exactly 3 times; the difference between the 1st and
the 3rd time is that footnote number 8 (footnote frame 34) doesn't exist
yet the 1st time, but is on page 1 at the 3rd time.
This reduces the space available in the body frame from 14040 to 13817,
and SwTextFrameBreak::IsInside() finds there's not enough space for the
last line.
Interestingly the sw_redlinehide didn't change anything here; this
reproduces in the same way back to OOo 3.3.
There's a few obvious ways to try and fix this:
a) The footnotes that are anchored beyond the end of the current text
frame are moved by RemoveFootnote() called later:
4 in SwTextFrame::RemoveFootnote() at sw/source/core/text/txtftn.cxx:508
5 in SwTextIter::TruncLines(bool) at sw/source/core/text/itrtxt.cxx:375
6 in WidowsAndOrphans::FindBreak(SwTextFrame*, SwTextMargin&, bool) at sw/source/core/text/widorp.cxx:338
This could be done earlier, in IsInside(), which already tries to do 2
other things to get more space, so it seems plausible that footnotes
which are known not to be in the frame (including the line that
doesn't fit) could be moved off the page.
b) An approach similar to commit e37ffdd118da2d21c5e78e8c7b67252d0d1adc8c
"tdf#125685 sw: disregard footnotes in follow table on table split"
would be to temporarily add the footnotes anchored beyond the current
frame to the available space, and leave them to actually be moved
later.
c) When RemoveFootote() is called and it does move a footnote,
invalidate its anchor text frame so that it gets formatted again.
This seems to have the highest risk of introducing loops though.
Let's try out a) for now and see how it works.
Change-Id: I54b59637b79d67f5eca61f11bd575145f244381f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88714
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: I9c0968bd93f41f983468ee7ba8a20e27c4866b32
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87954
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia7c987dc59f335d76ee874c1bb51707cb55ff41e
Reviewed-on: https://gerrit.libreoffice.org/84922
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Also drop a duplicated blacklist rule found with:
grep :$ sw/IwyuFilter_sw.yaml | sort | uniq -cd
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ied72f3f086ed4c1eb7ff4bcdbcf8aee73ddd4f7c
Reviewed-on: https://gerrit.libreoffice.org/83250
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I63ab268d908477f8847b315f44f6ffd543b17794
Reviewed-on: https://gerrit.libreoffice.org/76969
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
The bugdoc loops on calculating the follow of SwTextFrame 560, the one
containing "Hiermit nehme ich das Angebot an" in a cell with rowspan 3,
while the table is being split and its first row (also now its last
i.e. split row) is being formatted.
Loop in CalcFollow() because the follow is in the same upper frame as
its master and cannot move forward, so the 2nd call to pMyFollow->Calc()
after pMyFollow->Prepare() always sets the SetPrepWidows() flag on the
master and in that case the loop never terminates.
The problem is that the check in WidowsAndOrphans::FindWidows() of
GetThisLines() uses stale cached data - the value returned is 4, but
the frame contains fewer lines at that point and doesn't have lines to
spare for the follow; the cached value is only updated at the end of
SwTextFrame::Format(). Fix it by calling ChgThisLines() here.
But this fix only helps for the first SwTextFrame in a cell; the next
one with id 561 loops in a similar way. The problem then is that
SwTextFrame::PrepWidows() always calls SetPrepWidows(), even if the
Orphan-rule of the frame prevents it from giving lines to the follow.
Fix this by calling SetPrepWidows() only if lines are removed.
This also helps for the 2 attachments of tdf#118104.
(regression from commit 18765b9fa739337d2d891513f6e2fb7c3ce23b50
particularly the change in SwFrame::IsMoveable()
in the sense that it didn't loop before but there isn't anything
obviously wrong with this commit)
Change-Id: Ia1e5928a6510e68520b29eb265e26ffd0627c52e
Reviewed-on: https://gerrit.libreoffice.org/68402
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
Change-Id: I18edeff43fcae98514c80d9f2c1594cc2f866e75
Reviewed-on: https://gerrit.libreoffice.org/68401
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
...where "inline" (in its meaning of "this function can be defined in multiple
translation units") thus doesn't make much sense. (As discussed in
compilerplugins/clang/redundantinline.cxx, exempt such "static inline" functions
in include files for now.)
All the rewriting has been done automatically by the plugin, except for one
instance in sw/source/ui/frmdlg/column.cxx that used to involve an #if), plus
some subsequent solenv/clang-format/reformat-formatted-files.
Change-Id: Ib8b996b651aeafc03bbdc8890faa05ed50517224
Reviewed-on: https://gerrit.libreoffice.org/61573
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I58e9b241e543e72be410d88f640635e9dbe42ff0
|
|
This reverts commit 8bc951daf79decbd8a599a409c6d33c5456710e0.
As discussed at
<https://lists.freedesktop.org/archives/libreoffice/2018-April/079955.html>
"long->sal_Int32 in tools/gen.hxx", that commit caused lots of problems with
signed integer overflow, and the original plan was to redo it to consistently
use sal_Int64 instead of sal_Int32. <https://gerrit.libreoffice.org/#/c/52471/>
"sal_Int32->sal_Int64 in tools/gen.hxx" tried that. However, it failed
miserably on Windows, causing odd failures like not writing out Pictures/*.svm
streams out into .odp during CppunitTest_sd_export_ooxml2. So the next best
approach is to just revert the original commit, at least for now.
Includes revert of follow-up 8c50aff2175e85c54957d98ce32af40a3a87e168 "Fix
Library_vclplug_qt5".
Change-Id: Ia8bf34272d1ed38aac00e5d07a9d13fb03f439ae
Reviewed-on: https://gerrit.libreoffice.org/52532
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
which triggered a lot of changes in sw/
Change-Id: Ia2aa22ea3f76463a85ea077a411246fcfed00bf6
Reviewed-on: https://gerrit.libreoffice.org/48806
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Isolated all Frame AreaDefinition and it's layout flags to
SwFrameAreaDefinition class which is now base for SwFrame.
Adapted calls to get/set and WriteAccess hekper classes accordingly.
This allows much deeper understanding what Writer is doing when
layouting it's frames and needed when reaction on such changes
is necessary
Change-Id: I96220a1d140e69c76cc63023aae26e4ed17f3504
|
|
Change-Id: I6cce40ec49dd5bd32d94fe06b9d2dabd368448be
|
|
To gain more control over changes of the Writer layout,
isolated mentioned members and replaced all calls with
inline methods for read and/or write access. Moved to
own class to also identify 'private' accesses reliably.
Change-Id: Ib0b7f852f5176744e860e2aad12dd13c9a906d68
|
|
Change-Id: Ifc3c4c31a31ee7189eeab6f1af30b94d64f2f92a
|
|
Change-Id: Ic42b2691869b61ba906222db893e284d8b9c39c1
Reviewed-on: https://gerrit.libreoffice.org/40767
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic6829542628ed1f5ed7d6b3d6be1d28ed1b5c75b
Reviewed-on: https://gerrit.libreoffice.org/37292
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
To complete commit 076758857a98
Change-Id: I6424109e3aee8a3236e40168bdd98c725a7afafb
Reviewed-on: https://gerrit.libreoffice.org/37306
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Translate German comments and terms in sw/
Change-Id: Idc788ab3a62d29489893e086a51329ace59a6465
Reviewed-on: https://gerrit.libreoffice.org/36401
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I52604902247e7d8565476fafe98211fff32c5543
Reviewed-on: https://gerrit.libreoffice.org/35658
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ib725427225fe95fb39a72f96bbd60d5464c9351a
Reviewed-on: https://gerrit.libreoffice.org/34782
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: I8aab9004001a9a2ddd54b4c73857b6f9c5b51515
Reviewed-on: https://gerrit.libreoffice.org/33486
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Takeshi Abe <tabe@fixedpoint.jp>
|
|
Change-Id: I700e51dbfe0768642d482556299407f8f198e998
Reviewed-on: https://gerrit.libreoffice.org/31709
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: Idc2118899a8063099b66c0f5db40d8402db063d1
Reviewed-on: https://gerrit.libreoffice.org/30083
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib400c5930be84d26665b0e12a61508c8fbfd7f08
Reviewed-on: https://gerrit.libreoffice.org/29105
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I27ff0f4f0eb395d7e0a60dd604758c220a3134c4
|
|
Turn in-line version control history comments into meaningful good comments.
Change-Id: I3b8ec19fc59f7c816696167cb64238ef35464341
Reviewed-on: https://gerrit.libreoffice.org/23380
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
As suggested at <https://gerrit.libreoffice.org/21445>.
Change-Id: Id1e7a6381954c6d56a2593a064c37cc185475a56
Reviewed-on: https://gerrit.libreoffice.org/21899
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
To have the "we want the difference vs the nominal size, not the actual
size" code at a single place.
Change-Id: I9b4b9a33d5d2da825c5da93e69790277eba8d0b3
|
|
... paragraphs that would otherwise fit nominal size of the page frame
Change-Id: I90c3de9150b17c951e1ac4158babb7a71afee9ee
|
|
This commit renames the most annoying abbreviations in Writer (and
partially in the shared code too).
Change-Id: I77e5134f42f25e3786afa36b7a505c7e3237a9e8
|
|
Change-Id: Id1d6166ee8c1c3558746da1d7bb5ad2163a87845
|
|
It's a class, not a macro anymore.
Change-Id: Ia8414d430b2889c834457d8bfd2aa338f2ed994a
|
