...as emsdk 5.0.3 deprecated the predefined EMSCRIPTEN macro (see
<https://github.com/emscripten-core/emscripten/commit/506052bd8b4e23ded7f2351c62ca3b24d40c8cf3>
"Warn about usage of deprecated EMSCRIPTEN macro. NFC (#26381)"), causing
failures like
> In file included from static/source/unoembindhelpers/PrimaryBindings.cxx:29:
> In file included from include/sfx2/viewsh.hxx:35:
> In file included from include/editeng/outliner.hxx:32:
> In file included from include/tools/color.hxx:26:
> include/osl/endian.h:66:15: error: macro 'EMSCRIPTEN' has been marked as deprecated: use __EMSCRIPTEN__ instead [-Werror,-Wdeprecated-pragma]
> 66 | #elif defined EMSCRIPTEN
> | ^
> /home/sberg/emsdk/5.0.4/emsdk/emscripten/main/cache/sysroot/include/emscripten/emscripten.h:35:66: note: macro marked 'deprecated' here
> 35 | #pragma clang deprecated(EMSCRIPTEN, "use __EMSCRIPTEN__ instead")
> | ^
To avoid confusion, also suppress the -D$(OS) in
solenv/gbuild/platform/unxgcc.mk that would unnecessarily keep defining
EMSCRIPTEN.
Change-Id: Ic1f187cf1c6417cd95d4092e9cea01a665bd1b2f
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/34
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 50291c2ed83bdb49bb827a4a12905d94b8c42035)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205167
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This change makes two adjustments to the Syriac justification kashida
insertion position algorithm:
- Previously, the first pass scanned from end to midpoint exclusive.
This has been updated so kashida positions at the midpoint are
prioritized over kashida positions in the first half of the word.
- Fixes a bug that made midpoint calculation include vowel marks and
other diacritics.
Change-Id: I615cde5cdb54e7afe5fccdf4d536ce7aef211395
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204141
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
Updates Writer to visually indicate the following Unicode bidi control
characters when "Show Formatting Marks" is enabled:
- U+200E LEFT-TO-RIGHT MARK
- U+200F RIGHT-TO-LEFT MARK
- U+202A LEFT-TO-RIGHT EMBEDDING
- U+202B RIGHT-TO-LEFT EMBEDDING
- U+202C POP DIRECTIONAL FORMATTING
- U+202D LEFT-TO-RIGHT OVERRIDE
- U+202E RIGHT-TO-LEFT OVERRIDE
Change-Id: I1989eb793f8f89633c067a4bcbf0f1245dc0b9f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203132
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
This assumption is false e.g. for Microsoft XPS Document Writer, where
both portrait and landscape paper are in the list. The orientation and
the size of the paper must be detected from the dimensions.
Change-Id: Ibcfc68f64243ec144743a385f73586ca67f0cbe5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199824
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Implements the ODF 1.2 paragraph attribute style:writing-mode-automatic,
and supporting runtime features. When set, this attribute allows
programs to automatically recompute the paragraph writing mode when the
contents of the paragraph have been edited.
The ODF standard does not suggest any particular algorithm for
automatically determining paragraph direction. This implementation uses
the rules from Unicode UAX #9 3.3.1.
Currently, LO will only automatically change the writing direction when
new text is typed or deleted. Other known interesting cases are already
tracked as separate enhancement requests.
Change-Id: I49eecea36952588dc98f2a98ebce712cd2846c0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193547
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
I think that these functions may easily be used in different threads.
No idea how useful the cache is (if at all: do we call the functions
repeatedly for same character often enough?); but at least it must be
correct.
Change-Id: Ide2f7317bed55e201cd075ca93ee617e16a2654e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192678
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Previously, when authoring documents containing multiple languages,
certain characters (e.g. smart quotes) could use the wrong/undesired
font. For example, if a Chinese word is quoted inside English text, the
right quotation mark would use the Chinese font rather than the
intuitively-expected English font. Users had no way to control this
behavior.
With this change, Writer will now set an appropriate style:script-type
hint when the user manually specifies a language for a selection in the
user interface. This can be used to quickly correct instances of the
above problem.
Change-Id: I6f8c924d230e3518272e2abb1cbea5e0e7451e9b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186394
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
Users of ToggleUnicodeCodepoint keep reading next characters to the left,
until AllowMoreInput returns false (or selection ends). Attempting to
read more characters to the left then there are, SwCursorShell::GetChar
returns 0. This needs to be treated by AllowMoreInput as hard stop. It
failed, when the previous character was a combining character.
Change-Id: I203b150154e1948d4cebfd69442e30a076710f46
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186341
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Implemented the ODF 1.0 style:script-type text property. This property
can be used by documents to influence which script type-dependent
attributes are used when rendering certain characters.
This implementation uses the following semantics:
- If unset, the behavior is as it was in previous versions.
- If set to latin, asian, or complex, those characters not mapped by the
ODF standard to a script type are treated as latin, asian, or complex,
respectively.
- If set to ignore, all characters will be treated as latin. This value
is intended to be used for interoperability with file formats that
don't implement script types (e.g. HTML).
Change-Id: If81a1390ee455fd971dea655d161d9c3f44fd08a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186309
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Regression from 537645c083
"tdf#66791 sw: Treat weak punctuation as Asian in Asian paragraphs"
The fix for tdf#66791 extended the script change scanner to always treat
weak quotation-like punctuation as Asian script in paragraphs containing
Asian characters. That new behavior emulates the behavior of other word
processing programs.
Unfortunately, the change proved too disruptive. This change
substantially reverts the new behavior added for tdf#66791, but leaves
the refactoring and testing work intact.
Change-Id: I9eaf91f27a4e8f7440c949a713c6b64fe8dc579b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185812
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
We either expect a single (maybe combined) character to convert into "U+"
notation, or a sequence of hexadecimal numbers (possibly with U+) for
conversion to characters. If we already saw a hexadecimal ASCII character,
it can't be preceded by a character combining with it, so stop as soon as
such an unexpected character appears.
Change-Id: Ic480fe8f173240eb263d5a77286b149c933049a6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181007
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Fixes ofz#385256118 Timeout on ImpEditEngine::InitScriptTypes.
Previously, the script assignment algorithm could backtrack in certain
cases where a script run ends with weak characters that should be
included in the following run. Fuzz testing unearthed a case involving
right-to-left override and a CJK combining mark, which caused the
algorithm to make no progress and hang.
The algorithm now always makes progress on each iteration.
Change-Id: I4da138c51d391c152afcee2428c21dc762a2dafc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/179888
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Previously, leading weak characters were always assigned a script type
derived from the application language. This change updates the algorithm
to instead use the logical-order first-seen non-weak script type.
Change-Id: I5f6732c6faa1eb35aff51e98e82a87c8008f70ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/179824
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Previously, Asian-script characters following an explicit direction mark
or inside an RTL embedding would be rendered using the Complex font,
rather than the Asian font. This change updates script detection to
treat these characters as Asian regardless of text direction.
This change also consolidates more duplicated script detection code from
Writer and Edit Engine.
Change-Id: I3931c3ec0cb447f3c504fdbfb3ee62185fd14422
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178817
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
This change modifies script detection to treat certain weak punctuation
marks, particularly left- and right- quotation marks, as Asian script in
paragraphs containing Chinese and Japanese characters, but no Complex
characters. This change improves our script detection compatibility with
other programs.
As part of this change, duplicated script detection code has been
extracted from Writer and Edit Engine, and consolidated.
Change-Id: Ib2880f2e832aaac4c0093971daa88223c7232d63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178608
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
V1037 Two or more case-branches perform the same actions. Check lines: 438, 446
V1037 Two or more case-branches perform the same actions. Check lines: 442, 450
V1037 Two or more case-branches perform the same actions. Check lines: 483, 659
V1037 Two or more case-branches perform the same actions. Check lines: 492, 896
V1037 Two or more case-branches perform the same actions. Check lines: 501, 791, 944
V1037 Two or more case-branches perform the same actions. Check lines: 549, 725
V1037 Two or more case-branches perform the same actions. Check lines: 552, 842
V1037 Two or more case-branches perform the same actions. Check lines: 618, 642
V1037 Two or more case-branches perform the same actions. Check lines: 648, 734
V1037 Two or more case-branches perform the same actions. Check lines: 698, 854
V1037 Two or more case-branches perform the same actions. Check lines: 974, 977
Change-Id: Iadd03f3813deaffcebdb1a661489b86b83bf9d5b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175219
Reviewed-by: David Gilbert <freedesktop@treblig.org>
Tested-by: Jenkins
Currently, we use HarfBuzz-provided kashida insertion position
information to decide on positions to insert kashida. This data is used
both while ranking kashida insertion positions, and to avoid inserting
kashida in positions that would break shaping on a per-font basis.
Unfortunately, HarfBuzz cannot validate kashida insertion positions for
AAT fonts. As a result, kashida were previously not inserted for text
using AAT fonts.
This change updates kashida justification to skip validation against
HarfBuzz when AAT fonts are used.
Change-Id: If0d31512b1db0f1f8155963f9b1031eb01bacc45
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175165
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Commit c3c29d31d7 (tdf#140767 Implemented
Syriac justification) indirectly introduced a font-dependent infinite
loop in Writer layout by relaxing some restrictions on kashida candidate
positions. The infinite loop was found in tdf97806-2.odt.
This change fixes an underlying logic bug in Writer, which caused Writer
to attempt to apply kashida justification to non-Arabic/Syriac CTL
scripts. This change also reintroduces some of the previously-lifted
restrictions on kashida candidate positions.
Change-Id: I783bf327f4ef0f1f6a032f0d3dddbcfd60a026fa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174503
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Previously, Writer and Edit Engine would skip inserting kashida in words
if the highest-priority candidate position is marked as invalid by
HarfBuzz. This would happen even if the word contained multiple
lower-ranked valid candidate positions.
This change updates Writer and Edit Engine to pass HarfBuzz kashida
position data to the selection algorithm. The algorithm has been updated
to return the highest-priority valid position, if any. The algorithm has
also been updated to use raw positions marked as valid by HarfBuzz as a
fallback, if no better positions could be found.
Change-Id: I40c6432c4607aee197e8767e5667db504469956a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173963
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Small tweak to the kashida insertion rules to restore some previous
behavior. Kashida should not be inserted after a final Yeh, but should
be inserted after an initial or medial Seen, even if it is followed by a
final Yeh.
Change-Id: I1fef2d32961c6f55006b2df456827588f62af40b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173889
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
This change partially reverts the fix for tdf#65344, to allow more
candidate kashida insertion positions.
The final position fallback from the original ruleset has been restored.
Instead, tdf#65344 is now fixed by explicitly prohibiting kashida under
a final-position Yeh.
Change-Id: I9fe8c656768777c160205ad9892f2fe916a2a926
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173887
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
The kashida candidate position selection logic was copied-and-pasted
from Writer into Edit Engine. This change consolidates the shared code
into a library. This change also adds some minimal characteristic tests,
which previously did not exist.
Change-Id: I2bfbfa79858347803474b754566436f3e74d1a54
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173883
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
Most of these don't use boost themselves, nor do they need
it transitively since the use of boost::optional was removed
Change-Id: Ic9dee1c4e160b313ec5b91677b02ffdea6c5779d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164440
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
It can’t be easily made to work when mixing our case folding data (which
seems to work on individual surrogates) and ICU functions, so port it
over completely to ICU.
Change-Id: I0e12b81b23a053a2a9a299e51908930a3d0b82d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154843
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@libreoffice.org>
It was mapped to uppercase sigma (U+03A3) while it should be mapped to
uppercase lunate sigma (U+03F9). Fix by letting this slot fallback to
ICU case folding.
Change-Id: I14ffa0151c740779b67af14be8c7af8c51c3a1e0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154845
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@libreoffice.org>
If we are requested to case map a character not present in our case
mapping data, fallback to ICU case mapping functions.
We should switch completely to ICU at some point, but we need to
evaluate our case mapping data and see if it differs from ICU and if
there is a reason for it.
Does not handle the case of U+03F2 turning into Sigma from tdf#97152.
Change-Id: Icf13ac7aab6d07b2a90fc0ff5ef1c4f50c7a7f8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154803
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@libreoffice.org>
Andrea Gelmini