Age | Commit message (Collapse) | Author |
|
Previously, Writer was not correctly terminating layout contexts at the
starts of small caps spans. This could cause incorrect character
placement in certain cases.
Regression since:
Commit 30d376fb7ded4c96c85ad1112a0e44b5929657c9
"tdf#61444 Correct Writer text layout across formatting changes"
and
Commit ab0a4543cab77ae0c7c0a79feb8aebab71163dd7
"tdf#124116 Correct Writer text shaping across formatting changes"
Change-Id: I863b9b66356eb0a9efb5bbdc75e80b43d56aaaf0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177839
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
|
|
Commit 2b47fae7e3e23ee7c733708500cb0482ad7f8af1 introduced the
compatibility setting ApplyTextAttrToEmptyLineAtEndOfParagraph, but that
was probably a mistake.
What Word is doing there is not applying a text attribute but applying the
formatting of the paragraph marker; add a new compatibility setting
ApplyParagraphMarkFormatToEmptyLineAtEndOfParagraph to do this.
Change SwAttrIter to apply the RES_PARATR_LIST_AUTOFMT formatting when
the position behind the last character is reached, and use it to set the
height of the last line in SwLineLayout::CalcLine() in case it is empty
or contains only spaces/tabs.
Frustratingly this requires another change to fdo74110.docx to get rid
of some odd font that's applied to the paragraph marker.
Also, change SwTextFrame::IsHiddenNow() to take into account paragraph
marker formatting; if all characters are hidden but the paragraph marker
isn't hidden, the paragraph is still displayed in Word.
Change-Id: Icccd3e822ad0301ccbe373b50431c3254f691d6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173880
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Unfortunately the actual computed margins are not stored in text
formatting data structures so are only available directly from
SwTextMargin.
Change-Id: Ia7ce5e148194a55b5d9874ed112aaa977ed16c7b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166258
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: Ibefb8549834ba5011286e3221f1ae276e2c0c0bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141153
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I2104cad267e6f704f9389b03ff3f116fca875517
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108796
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Idbd13674578be9d4edce5d2a5f45df145474d86d
Reviewed-on: https://gerrit.libreoffice.org/72579
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
The bulk of this commit is reasonably straightforward, the interesting parts
are:
- SwFrame::CheckDir() is where the layout reads the doc model, i.e. sets the
new SwFrame::mbVertLRBT.
- We had 3 text directions previously: horizontal, vertical (implicitly RL) and
vertical LR (implicitly TB). This adds a 4th text direction for the LRBT case.
- SwTextFrame::SwitchHorizontalToVertical() is responsible for re-locating the
origo of a string to be painted from the top left to the bottom left corner (in
addition to the height/width swap that's done for all vertical directions).
- Finally MapDirection() is the place where we map Writer's new btlr mode (with
no character rotation) to VCL's 900 (90 degrees) rotated direction.
No functional changes intended for existing text directions. Lots of places are
still not yet adapted, but this is good enough to paint a single word in a
table cell at the correct position with the correct direction.
Change-Id: I465c62db6562d8a2be140c3d37473e590830139e
Reviewed-on: https://gerrit.libreoffice.org/67740
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
It turns out that there was a small problem in the interpretation of
sw_JoinText(), or rather, its caller,
SwRangeRedline::DelCopyOfSection(), which, since about OOo 3.2 and
i#100466, passes in bForceJoinNext, so the result is that the first node
wins always, not just for RES_BREAK/RES_PAGEDESC items.
This means that pParaPropsNode and pFirstNode are the same thing really.
Another little problem is that the SwAttrIter was initing the font
wrongly: the relevant items are the items in the *current* node's item
set on top of the item set of the paragraph style, i.e. the *first*
node's style.
Simple reproducer: ooo79457-1.odt
Change-Id: I06ef3c1695b8f3cdbded238864a60d5eb9ce4c44
|
|
This never called Rst() in the loops because the m_nPosition wasn't updated.
Change-Id: I5a9cf47d9fe6d92bb7fccf255acbbd22f04b7f47
|
|
rename the "magic" members and fields that are actually a font-cache-id,
to more useful names
Change-Id: Ie787b0939115c576e979c7e27a21a68c138c32f6
Reviewed-on: https://gerrit.libreoffice.org/59868
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I08c91c9c84d53f567332e5780b14173b8c8e5fb1
Reviewed-on: https://gerrit.libreoffice.org/57462
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I204250a02ac88cc36267b79ef1d70cd361230752
Reviewed-on: https://gerrit.libreoffice.org/57245
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
... and use it in SwTextPainter::CheckSpecialUnderline()
Change-Id: I904cb955f0bc8dc1f92612b47dc129922865c198
|
|
Just get it from the current node when needed; it's a trivially
inlinable function call.
Change-Id: Ic2ba291fb43da263300ddaedc9ae21cd86cb07ac
|
|
... because it's only used as an optimization currently, so we just use
the slow-path if there is a merged paragraph.
Change-Id: I8b577174e65edd0e5210971511e054fd719de96a
|
|
... so we can call it again later, when the text node changes.
Change-Id: I4cd2ff064b829a70652bf1861bacf365be7277a2
|
|
Just use the mapping functions in GetNextAttr().
Change-Id: I4108e62ffbefbf3b0afe03b31ff97013969ea3a3
|
|
Change-Id: Icdadd3d9daa5c0031c044004032723d7108d71ab
|
|
Change-Id: I304c333bb6aaca8933606b662743a1642c655de5
|
|
hints, so replace it with something less dangerous.
Change-Id: If35cf8157e6b88ee6873789847ed9c5ceea6e37e
|
|
Change-Id: Id02fbcf5112358fb12f4069e5bedc3292ad200b1
|
|
That's a bunch of new code.
Change-Id: Ibb0170bf398c5e09bce75797206710de9b9ee893
|
|
Add the data to ParaPortion for now; there is one per SwTextFrame but
there doesn't seem to be anything currently in the layout that exists
once per SwTextNode.
Change-Id: Id86f742f09e5036485690acbe6f831ba9f69c08c
|
|
Change-Id: I44705fc14f5a7013da3b6425b0e001c03f617f19
Reviewed-on: https://gerrit.libreoffice.org/54371
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
Change-Id: Ifc3c4c31a31ee7189eeab6f1af30b94d64f2f92a
|
|
Change-Id: Ida715fad0c4587a9566184180bf159da12470dd7
Reviewed-on: https://gerrit.libreoffice.org/43207
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
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>
|