Rewrite font family and subfamily to use typographic names if they are
using legacy names, so we can elsewhere always assume typographic names
are used.
Change-Id: I8db2d4cf801c50794ff38b7d9e6d8419e66f5680
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207547
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
Tested-by: Khaled Hosny <khaled@libreoffice.org>
Completes the deprecation of legacy coordinate subsystem naming by
renaming GetOutOffYPixel() and SetOutOffYPixel() to
GetDeviceOriginY() and SetDeviceOriginY() across OutputDevice,
Window, and CoordinateMapper.
This unifies axis naming conventions following previous X-axis
refactoring passes, clarifying that these fields represent the
physical origin offsets of the device rendering canvas.
This patch also moves view transformation logic inline from outdev/map
to CoordinateMapper, and wraps sprawling multi-line logic formulas
across mapping routines to clean up formatting boundaries.
Key changes:
* include/vcl/outdev.hxx / window.hxx: Updated public declarations
to replace GetOutOffYPixel with GetDeviceOriginY.
* vcl/inc/CoordinateMapper.hxx: Migrated view transformation cache State
members and mapping calculation methods into the mapper object.
* Global adjustments: Patched all related coordinate offset reads
and tracking writes throughout desktop, editeng, sc, svx, and vcl.
Change-Id: I28fec54a7f3312cc41ada2de38b26351c0a65527
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203646
Tested-by: Jenkins
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Rename GetOutOffXPixel() and SetOutOffXPixel() to GetDeviceOriginX()
and SetDeviceOriginX() across OutputDevice, Window, and CoordinateMapper.
The legacy "OutOff" naming convention obscured the difference between
system-level window positioning offsets and internal content scrolling
(SetPixelOffset). The new nomenclature explicitly communicates that
these metrics strictly govern the device coordinate space origin.
This patch focuses strictly on the X-axis coordinate reads and cleans
up duplicated formatting signatures inside the CoordinateMapper header.
Impacted modules:
* include/vcl: Update public declarations in outdev.hxx and window.hxx.
* vcl/inc: Clean up CoordinateMapper.hxx whitespace and scaling hooks.
* Global: Patch dependent pixel coordinate reads across desktop, editeng,
sc, sfx2, svx, and vcl.
Change-Id: I546e1d255887e3b280ff15caca2e27ef10de52d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206509
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Tested-by: Jenkins
When an apostrophe or quotation mark is typed, autocorrect replaces it
with the matching typographic quote. This was done in two edits: the
typed straight character was inserted first, then replaced with the
typographic one. Since each edit is its own undo step, undoing the
autocorrect first turned the quote back into a straight quote and only a
second undo removed it. In languages that never use straight quotes, for
example French, typing 'un and undoing left a stray straight quote in the
text.
Build the typographic quote with a single edit, so one undo removes the
whole quote.
The change is limited to the quote handling. Autocorrections that insert
a character and then act on something else, such as turning a web or mail
address into a link after a space, keep their existing per-step undo
Change-Id: Ibf47fb8f37d29d5ba180ed692f730d20e9f3e431
Signed-off-by: Pranam Lashkari <lpranam@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/5897
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit e2ba52e1996f81ff3b93fa70ecf625b7709d07fb)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207621
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
To solve the trade-off between better spacing and less hyphenation,
support hyphenation level and its user interface, the hyphenation
slider, like DTP software do.
Add new paragraph property com::sun::star::text::ParaHyphenationLevel
The hyphenation slider is the basic interface of DTP software to adjust
single (or all) paragraphs using better word spacing (i.e. more
hyphenation) or less hyphenation (i.e. worse word spacing). It allows 1)
to choose the best from the near equally good layouts and 2) to solve an
extreme bad layout (caused by words without hyphenation or other corner
cases).
– 50% hyphenation level means disabled hyphenation, if minimum
and maximum word spacing settings allow to break the line within
words (default interoperability value).
– 100% hyphenation level means using extra hyphenation only if that
results better word spacing in the line, than breaking within words.
– Between 50% and 100% hyphenation level, use extra hyphenation only if
its weighted word spacing is better, than breaking the line between
words (weighting grows with the hyphenation level).
– Between 0% and 50% hyphenation level it means disabled hyphenation
with increased desired and maximum word spacing, depending on the
hyphenation level. At %0, the desired word spacing is enlarged to the
original maximum word spacing, while maximum word spacing is enlarged
by a single space.
For example, the original 4-page unit test document with the default 50%
hyphenation level contains 14 hyphenations. 100% hyphenation level
results in 22 hyphenations, while 0% only results in 8 hyphenations.
– sw/qa/extras/layout/data/tdf167648_minimum.fodt,
sw/qa/extras/layout/data/tdf169168_minimum.fodt: set maximum
word-spacing to 100% from 101% to limit the original unit test only
for minimum letter spacing.
More information: LO/COOL Book & Typography projects:
https://www.numbertext.org/typography/https://www.numbertext.org/book/
Follow-up to commit cf104be5cb "tdf#119908
tdf#166113 cool#15973 sw smart justify: fix DOCX hyphenation",
commit d572576dd6
"tdf#119908 cool#15973 sw smart justify: fix "smart" hyphenation",
commit 529755f091
"tdf#166113 sw smart justify: adjust algorithm for interoperability" and
commit 7d08767b89 "tdf#130088 tdf#119908
smart justify: fix DOCX line count + compat opt."
Change-Id: I84b3893ea6c5cd4eff74a73514722285e7071392
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207545
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: Jenkins
EditEngine dropped the SvxFontItem style name when building the layout
font, so the typographic subfamily never reached font matching. Without
it, say, font width, chosen could not be resolved.
Change-Id: Ib7a7cc9b051be14467ddac42b4e5458b5c0327c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207295
Tested-by: Jenkins
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
In order to represent the (codepoint of a) Unicode character
in UTF-16, multiple UTF-16 code units may be needed.
So far, the Korean Hangul/Hanja character conversion
was assuming that each Unicode character was only
consisting of a single UTF-16 code unit, and splitting
into single sal_Unicode characters accordingly in
TextConversion_ko::getCharConversions.
This breaks for characters represented by multiple
code units, like "𡽜" (CJK Unified Ideograph [1],
unicode codepoint: 139100/U+21F5C) which is represented
by 2 UTF-16 code units.
As a consequence, an invalid OUString/UTF-16 string would
be passed to HangulHanjaConversionDialog::SetCurrentString
for some of the suggestions.
Fix this by no longer splitting into single sal_Unicode,
but use o3tl::iterateCodePoints to split into actual
code points.
Example: When using "Tools" -> "Language" ->
"Hangul/Hanja Conversion..." for a Korean text of
"한글맞춤법", the string of all characters for potential
conversions in TextConversion_ko::getCharConversions is:
"韓漢寒限閑恨旱汗翰邯罕悍澣閒瀚桿捍閈暵鼾犴僩嫺熯嫻駻鷳扞狠僴覵瞷猂邗骭撊鷴垾憪橌㸁䛞䦘闲鹇娴汉焊闬韩仠佷傼兯哻娨嫨屽晘橺浫澖皔蓒蔊蛝螒豻貋釬銲雗鶾鷼麲㒏㛠㡾㢨㪋㯗㲦㵄䁂䂅䈨䉯䍐䍑䎯䏷䓍䓳䕿䗙䥜䦥䮧𡽜忓"
Previously, the last 3 of them ("䮧𡽜忓") would incorrectly be
split into (stdout output, showing something is wrong):
"䮧", " " (something wrong, but a valid UTF-16 string), "?" (wrong, and invalid UTF-16 string), "忓"
With the fix in place, they remain intact:
"䮧", "𡽜", "忓"
Also adjust HangulHanjaConversionDialog::OnSuggestionModified
accordingly to compare the number of code points the
string consists of, not the number of UTF-16 code units.
Otherwise, the "Replace"/"Always Replace" buttons in the
"Hangul/Hanja Conversion" dialog would remain greyed
out for the above example when selecting the "𡽜" character
(that now correctly gets displayed with the fix in
TextConversion_ko::getCharConversions in place).
Thanks to Jonathan Clark for pointing out that additional
aspect in review!
Add a corresponding test case.
While the fix is in i18npool, the new test is implemented
in editeng, where the HangulHanjaConversion class uses
the i18npool logic via a UNO service.
The test is implemented there because the component context
availabe in i18npool doesn't supply the required service.
The same test implemented there would fail like this:
An uncaught UNO exception
- com.sun.star.uno.DeploymentException: {Message: "component context fails to supply service com.sun.star.linguistic2.ConversionDictionaryList of type com.sun.star.linguistic2.XConversionDictionaryList at /home/michi/development/git/libreoffice/workdir/UnoApiHeadersTarget/offapi/normal/com/sun/star/linguistic2/ConversionDictionaryList.hpp:45", Context: @0x7fff17acecf0}
[1] https://codepoints.net/U+21F5C
Change-Id: I1ab202cc0d3b5a6ff5d220f4b8e90c578f591158
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207017
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
In multi-user LOK Impress sessions, when SetUpdateLayout(true) is called
inside ImpMakeOutlinerView (e.g. during ShowSdrPage for a new user or
SdrBeginTextEdit), the EditEngine iterates all registered EditViews and
calls ShowCursor, HideCursor, InvalidateWindow, and InvalidateAtWindow.
Secondary EditViews created by the ShowSdrPage lambda for other users
can reference windows that have been disposed (user disconnected or
switched pages). These functions accessed the disposed window without
checking isDisposed(), leading to null dereferences of mpWindowImpl
(which is reset to null in Window::dispose()).
Crash path: SetUpdateLayout(true) -> EditEngine::SetUpdateLayout ->
mpActiveView->ShowCursor -> GetOutputDevice() ->
*mpOutputWindow->GetOutDev() -> dereferences null mpWindowImpl -> SIGSEGV.
Guard all EditView/ImpEditView functions that access the output window
against disposed state:
- ImpEditView::ShowCursor: early return when no callbacks and window
is null/disposed, since GetOutputDevice() and all subsequent cursor
positioning code requires a valid window
- ImpEditView::InvalidateAtWindow: check disposed before Invalidate()
- EditView::InvalidateWindow: check disposed before Invalidate()
- EditView::ShowCursor/HideCursor: check disposed before
GetParentWithLOKNotifier()
Also guard two loops in SdrObjEditView that iterate OutlinerViews and
access their windows without disposed checks:
- ModelHasChanged: skip views with disposed windows
- ImpInvalidateOutlinerView: check disposed in addition to null
Change-Id: I8b3e4c7d2a1f5e9d0c6b8a3f7e2d4a9b1c5f8e0d
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/939
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Signed-off-by: Andras Timar <andras.timar@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/1443
(cherry picked from commit 5b0d6592d3339e8e6514a4ef28929687636087c5)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207066
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
In the past, weld.hxx used to contain the class
definitions for weld::Widget and all subclasses.
By now, weld::Widget and almost all subclasses have
been moved to separate headers, to make it easier
to keep the overview and to avoid having to
recompile ~all UI code when one class changes.
By now, only weld::Button is left in weld.hxx.
Rename the header to Button.hxx.
Drop weld.hxx includes and instead add Button.hxx
includes (or weld::Button forward declarations) where
weld::Button is used.
(Don't simply replace all weld.hxx includes with
Button.hxx ones, since many of them were for the
use of other widgets that have since been moved
to their own headers.)
Add further includes where needed now that the
(direct or transitive) includes of weld.hxx were removed.
Change-Id: I8ea6201446a418d5e38b46337059dcd517ee29d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205937
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Add missing includes/forward declarations in places
previously depending on transitive includes that
are now dropped.
Change-Id: I3215b358e0fa45ffce08756218c386e1a4d7ebc6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205928
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Move the class out of weld.hxx into its own header and
source file, in order to make it easier to keep an overview
and to avoid having to recompile ~all UI code when the class
is modified.
Change-Id: I91bae842e5b18a83db45de12150c21f75e537fb9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205900
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Writer and Edit Engine use style:writing-mode-automatic direct
formatting to mark paragraphs for which the user has manually set a
paragraph direction. This is important to stop paragraphs from flapping
if the user sets a direction that disagrees with our heuristic, and then
keeps typing in the same paragraph.
This change updates Writer and EE to no longer extend this DF to new
paragraphs, such as those made by pressing enter while typing naturally
in a document. Previously, this DF was extended in a manner consistent
with other types of paragraph DF. That was conceptually valid, but in
this case it created some confusing results where automatic writing
modes would seem to arbitrarily stop working the first time an explicit
direction is set.
Change-Id: I54f2d522a72c504a5d27197bca526e4085381d8d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205505
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: If7cb4403f1861c465f44a1cae4065b0bf8dfad48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205323
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
If bSetNumRule and bSetNumRuleAfterSpace are set then auto formatting is
applied whenever space is pressed on a line with only two characters in
order to convert the two characters to a bullet point if applicable.
However this would also end up running all of the other auto-format
options such as removing trailing spaces. These aren’t designed to be
executed in the middle of editing a paragraph so it would end up
removing the space that the user just tried to type. This patch fixes
that by disabling any unrelated flags in SvxSwAutoFormatFlags before
executing the auto formatting so that only the bullet point formatting
will be applied.
A new method is added to SvxSwAutoFormatFlags to reset all of the flags
to false so that the bullet code can re-enable the relevant ones. In
order to avoid having a long list of assignments that is likely to get
out of sync as new options are added, the flag members of
SvxSwAutoFormatFlags are now declared using a macro that can be reused
to define the assignments.
Change-Id: I33155f45ba6cfd316222ad4d552beeb7979f8f4a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205225
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
The autocorrect functions take as arguments an abstract interface to a
document and a string reference containing the text for the paragraph
being updated. The string needs to be a reference to the actual text
used for the document because the functions rely on it being
automatically updated when modifications are made to the paragraph. This
causes problems when redlines are enabled and the text comes from a
MergedPara because some operations can cause the MergedPara to be
recreated. The SvxAutoCorrect::DoAutoCorrect function has many
workarounds to try and fix this problem. The one from the commit below
tries to fix it for the case where a small group of autocorrect
functions can all be run together by making a temporary copy of the
string. This isn’t ideal because the different functions can no longer
see the result of the other functions. This is particularly bad for the
Esperanto hat function that was added after the patch was created. For
example “cxu” at the start of a sentence will be corrected to “Cu”
instead of “Ĉu” beause the word capitaliser can’t see the result of the
esperanto hat function adding the hat so it only capitalises the letter
“c”.
To fix this this patch adds a method to SvxAutoCorrDoc to get the latest
version of the paragraph text. That way each function can query the
string at the start and it won’t matter if it comes from a recreated
MergedPara. Ideally I think we should eventually move all autocorrect
functions to use this method and then remove the rTxt parameter to make
the code a bit more robust.
commit 22baeb9f9e
Author: Andras Timar <andras.timar@collabora.com>
Date: Thu Mar 19 10:19:21 2026 +0100
sw autocorrect: fix use-after-free with track changes enabled
Change-Id: Id407be018bdfa31c6f4642a9503c65e4c9e736d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205235
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
When typing after a period in a document with tracked changes,
AutoCorrect's FnCapitalStartSentence (and other functions) modify
the document via rDoc.Replace. With track changes enabled, this can
cause the text frame's text to be freed and reallocated, making
the rTxt reference passed to DoAutoCorrect a dangling pointer.
Subsequent autocorrect functions (FnCapitalStartWord,
FnChgToEnEmDash) then read from freed memory, causing heap
corruption detected as STATUS_HEAP_CORRUPTION on Windows.
Fix by making a local OUString copy of rTxt before the block of
autocorrect functions that can modify the document, and passing
the copy instead of the potentially-dangling reference.
Confirmed with Valgrind (Invalid read at svxacorr.cxx:590 in
FnChgToEnEmDash, called from DoAutoCorrect line 1717).
Change-Id: I5e3f2c8d4a1b7e9f0c6d3a2b8e4f1a7c9d5b3e6f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202151
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 7fac4f1cbf880711f18084600f616aca2b326829)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205196
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Adds an AutoCorrect option that corrects text like “sxangxigxis” to
“ŝanĝiĝis”. The former is a common alternative way to type the special
Esperanto letters when the user doesn’t have the right software
installed to type them properly.
Change-Id: I822f4239667bf60dad77e60497488e04514d46a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205066
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
After loading the autocorrect config, the code tries to unset all of the
flags that weren’t set in the config. However, it was using a hardcoded
magic number for the mask and this wasn’t updated when the DOI option
was added. This patch changes the magic number to be a constexpr that is
declared next to where the flag enum is declared to increase the
likelihood that future contributors will notice it if any more options
are added.
Change-Id: Ieadeb12613e61e57c02e10167cafdf04d6bbbe07
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205042
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
This fixes a particuarly annoying habit of a trailing superscript
ordinal suffix getting dragged into the next bullet and causing
the unwary user weird small fonts, and non-aligned bullets.
Nail only the most obvious case, leaving multi-line superscript
in-place, and ignoring other attributes.
Include unit test.
Change-Id: I9ba5009ed17377e5c2f24c9edb74c3a1c1393cd4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199203
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 03ed94560aaa20070708b265d3a551c862718bc3)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204606
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Replace memcpy() with std::copy_n() in impedit3.cxx to improve
type safety by eliminating manual sizeof() calculations.
Change-Id: I8f0dc51007f211dbf22689a2a50916657d0c53f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204357
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
Balance word spacing within the consecutive lines
to get uniform grayness and less rivers for better
readability, enabled by the new paragraph property
com::sun::star::text::ParaComposer
and the following developments:
* Add Paragraph Composer checkbox on Alignment pane of the
paragraph formatting dialog window (not default yet);
* Implement paragraph composer: big word spacing of a
line is decreased by shifting the last word from the
previous line, only if the word spacing is better, than
before, and the increased word spacing in the previous
line doesn't exceed the Maximum word spacing (limited
paragraph composer);
* When Maximum word spacing is not greater than the Desired
word spacing, shifting of the last word is not limited
by the Maximum word spacing (unlimited paragraph composer)
* Add loext:paragraph-composer attribute, as LibreOffice
ODF extension;
* Add ODF unit tests for the limited and not limited
paragraph composer.
Note: "Smart justify" line breaking algorithm chooses
space shrinking (limited by Minimum word spacing)
only if shifting the last word isn't better based
on the desired word spacing. This was still a greedy
line breaking algorithm, resulting big word spacing
in the lines before a longer word.
The paragraph composer shifts the last word (or the
first part of the hyphenated last word) from the previous
line to decrease big word spacing in the actual line.
Note: balancing very big word spacing in narrow consecutive
lines can result vertical rivers. To avoid this, use limited
paragraph composer by setting maximum word spacing.
Follow-up to "smart justify", word spacing, letter spacing
and glyph scaling developments. Selected commits:
commit 529755f091 "tdf#166113
sw smart justify: adjust algorithm for interoperability",
commit 7d08767b89 "tdf#130088
"tdf#119908 smart justify: fix DOCX line count + compat opt.",
commit 7d6696757d "tdf#159923
sw cui offapi xmloff: add custom word spacing",
commit 5a48070f59 "tdf#126154
sw offapi xmloff cui: add min/max word spacing",
commit f83a04c510 "tdf#167648
cui offapi xmloff sw: add DTP-feature maximum letter spacing",
commit 3c53797210 "tdf#167648
sw letter spacing: implement minimum letter spacing",
commit 45ec7bd761 "tdf#168251
cui offapi xmloff sw glyph scaling: extend UNO/UX/ODF".
Change-Id: I727caad70536c86be524bc9d9b52bc71208c202a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203288
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: Jenkins
I implemented cardinal and ordinal numbering for text
using the current text language
instead of the program's locale language.
The preview is now shown in the text language.
Change-Id: I68d4ce5868adb7b5f4b6786947d2e529daab48aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201931
Tested-by: Jenkins
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
in CppunitTest_sw_ooxmlexport8
include/tools/color.hxx:111:27: runtime error: -1 is outside the range of representable values of type 'unsigned char'
in Color::Color(basegfx::BColor const&) include/tools/color.hxx:111:27
in (anonymous namespace)::lcl_compute3DColor(Color, int, int, int) editeng/source/items/borderline.cxx:60:16
in editeng::SvxBorderLine::threeDDarkColor(Color) editeng/source/items/borderline.cxx:108:12
in editeng::SvxBorderLine::GetColorIn(bool) const editeng/source/items/borderline.cxx:614:23
in svx::frame::Style::Set(editeng::SvxBorderLine const*, double, unsigned short) svx/source/dialog/framelink.cxx:108:28
in svx::frame::Style::Style(editeng::SvxBorderLine const*, double) svx/source/dialog/framelink.cxx:57:9
Change-Id: I17052694f0499aec671ca49ba3872953c161655e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202258
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
When Asian layout compression is enabled, full-width brackets in text
boxes were overlapping due to incorrect character type assignment.
In the context of Asian typography compression:
Opening brackets (e.g., U+FF08 '（') have space on their left side and
occupy the right side of the character cell. Thus, they should be
categorized as AsianCompressionFlags::PunctuationRight.
Closing brackets (e.g., U+FF09 '）') have space on their right side and
occupy the left side of the character cell. Thus, they should be
categorized as AsianCompressionFlags::PunctuationLeft.
This commit swaps the following full-width characters to their correct
compression categories to prevent abnormal overlapping:
Move U+FF08, U+FF3B, U+FF5B to PunctuationRight
Move U+FF09, U+FF3D, U+FF5D to PunctuationLeft
Corrects the regression from 3548c92453b9d0d85270bc6309a91c4107e49685.
Change-Id: I3320b7d931eb3b399978198c7772a6edcf2b9725
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201608
Tested-by: Jenkins
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
Khaled Hosny