Add a few bulleted lines to a text frame in an Impress document, copy
them, paste in Writer: the paragraphs are imported with no bullet marks.
ImpEditEngine::WriteRTF() emits a bare \level<n> for the paragraph's
outline level, which editeng's own RTF importer reads back as a
bulleted item, but sw's RTF import ignores. The PowerPoint RTF clipboard
markup for the same thing is the RTF 1.0 old-style numbering pair: a
{\pntext <bullet>\tab} fallback and a {\*\pn\pnlvlblt{\pntxtb <bullet>}}
destination that contains the bullet character.
Fix the problem by emitting that pair alongside \level<n>, from the
paragraph loop in WriteRTF(), when the paragraph's EE_PARA_NUMBULLET
at that outline level is of type SVX_NUM_CHAR_SPECIAL.
Signed-off-by: Miklos Vajna <vmiklos@collabora.com>
Change-Id: I18a022ac28d50a8b7557ee2282cd3fd8e7c37299
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/14439
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit b7002f07f475ce4eb5cf7309dfe8e59ba21ecd7a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211942
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
We had only one shared setting for the three script groups, which means
the same variation settings are applied to the three groups, which makes
no sense as they often use entirely different fonts.
Change-Id: I6f2a8b4d1c9e0357a6b2d8f4e1c7093b5a2d6e84
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209222
Tested-by: Jenkins
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
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>
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
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>
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>
C:/lo/core/editeng/qa/unit/core-ttest.cxx(2447): error C2672: 'CppUnit::assertEquals':
no matching overloaded function found
Change-Id: I9ff0a59fc3ee6de00ba3a54442f66feb66a9d25e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198042
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Updates Writer and Edit Engine to automatically set paragraph directions
when opening or pasting plain text.
Change-Id: I9c81b0313d6ab717c064c2bc35043a86f2c8ea5b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197924
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Found after running bin/find-unneeded-includes --headersfwd include/vcl/[A-Z]*
This shaves off about 100M input, not bad for such a small amount
of files checked
This time --headersfwd skips files that contain #if defs,
in hope of not breaking builds that are not checked by CI
(...except for include/vcl/BitmapTools.hxx - this was cleaned accidentally,
due to a bug in the bin/find-unneeded-includes script that is fixed
by the previous commit 930ff2b830
- but let's keep this anyway, it seems fine)
Change-Id: Ia8e49d94f6adb3cdbedbc40ffa56dbf846c9b6e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196235
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
Tested-by: Jenkins
To minimize the size of the output RTF, Edit Engine only emits font
attributes when either the font changes or when the script type changes.
In the latter case, Edit Engine was previously writing font attributes
inside a child scope, rather than the paragraph scope. Font changes
related to a language change would thus apply only to the first run of
characters in that language, while following runs would appear to use an
arbitrary language.
Change-Id: Iff38299bffaf3045cef5c6e71b8cab441ba0be39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186612
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
Fixes a bug causing editeng to insert kashida glyphs in positions where
there is not enough space for them. The root cause was failing to
account for the extra space used by blanks while rejecting candidate
kashida positions.
Change-Id: I1e22f758af0a88c2070f31cca040570f3a730c08
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184282
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Similar to commit a7a81b6fbe (tdf#164359
editeng RTF export: track unused parent styles recursively, 2024-12-18),
the follows of a style has to be tracked recursively as well, to avoid a
crash.
The Impress UI doesn't seem to have a way to specify the parent/next
name of a style, but you can definitely create such a follow chain from
test code and probably this is also possible via macros.
Fix this similar to the parent case, except here handle when a style
sets itself as a follow: that's what the default Outline N styles do in
Impress.
Change-Id: If3847add02061fdb9ba1e3fbf7c1fc42e3866209
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178786
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Start edit mode for the shape in the document, double-click on a word
which has a "level 2" bullet associated with it -> crash.
This is a regression from c8b607b7c0
(tdf#163883 editeng RTF export: fix broken offsets into the para style
table, 2024-11-19), the direct cause is that ImpEditEngine::WriteRTF()
maps all style pointers to a style ID and once we write the parent
property in the style table, we unconditionally dereference our search
result, because we know all styles should be in that map.
The root of the problem seems to be that once parent styles are marked
as used for the "only write used styles for the clipboard" case, those
parents themselves can have parents, and we didn't mark those as used.
Combined with the unconditional dereference, this leads to a crash. Fix
this by walking up the parent chain till we get no parent.
This assumes that importers create a valid document model, so there
can't be loops while walking the parent chain. If that would be a
problem in practice, we could check for that in the future.
Change-Id: I4b416e78f26bf455040d95ee8ed220cfe870e33a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178703
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Regression from commit 70d1bd6ee0eba9d6661cd6280566f77a87f2d068
(tdf#161652 editeng, RTF copy: only write used paragraph styles,
2024-06-20), type a few characters into the title placeholder shape in
Impress, switch to the Outline view, select all, copy, paste into
Writer: the resulting text nodes won't have paragraph styles, just
direct formatting.
Inspecting the produced RTF, the problem is that the styles table
started to omit unused styles, but the style -> offset mapping table
still included them, so the offset didn't match, which results in losing
the style on RTF import.
Fix the problem by building the mapping table later also also ignoring
unused paragraph styles there, to restore consistency between declaring
style entries and referring to them.
Change-Id: I9156a881543cc710eb12990f110ceefc77a1858b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176747
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
which allows us to eliminate a bunch of rounding at various layers, and
consequently maintain a lot more precision
Change-Id: I911dedd7c041c1d67396c082e5695346ea689acb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175814
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This change updates editeng to clear the kashida array during layout, at
the same time it clears other justification data.
Previously, editeng could recycle stale kashida arrays and apply them to
lines with different lengths. This would result in stray kashida
rendered at inappropriate positions in lines, or accessing memory past
the end of the kashida array, resulting in assertions or
nondeterministic crashes.
Change-Id: I9c06239298d630f2d61b5e67a54f4c3e079c1193
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172967
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
Commit 937023bca4 aggravated a bug that
would cause editeng to use stale kashida positions after document
changes (for example, font changes). This could cause crashes or
spurious kashida, and both much more often after the above commit.
This change fixes the underlying logic error.
Change-Id: Id6465e739740a38ed11c9d9378d30faa51948731
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172866
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
SvxAutoCorrDoc::ChgAutoCorrWord() implementations: correct multiple patterns
* include/editeng/svxacorr.hxx, editeng/source/misc/svxacorr.cxx:
- Add classes SvxAutocorrWordList::{Iterator,WordSearchStatus}.
- Make SvxAutocorrWordList::SearchWordsInList() return WordSearchStatus
so the search can be continued with the added
SvxAutocorrWordList::SearchWordsNext() method.
- Make SvxAutoCorrect::SearchWordsInList(), and its lcl_SearchWordsInList()
companion, return WordSearchStatus propagated from
SvxAutocorrWordList::SearchWordsInList().
- SvxAutocorrWordList::WordMatches():
The existing mechanism of preventing collision of patterns like in
tdf#83037 (→ and ← and ↔ autocorrect collisions) was by storing
the matched string of wildcard pattern back to the list without
overwriting existing one. If the matched string was found in the list,
it would just be treated as no matching.
While this worked well for collision prevention, it caused failure
on the new exhaustive wildcard pattern visiting method when autocorrecting
the second text chunk with the same content. In such situation,
all intermediate stages of corrections of the first text chunk would be
recorded into the list. And, in the second chunk, the first stage would
just be applied from the recorded pattern, but all the next stages
would be refused due to the "collision" with the recorded patterns.
Moreover, the new method would cause the list to grow more quickly
as the autocorrections are done.
To solve the problem, just "peek" for the collision instead of
actually storing it. And SvxAutocorrWordList::ContainsPattern()
is added for this purpose.
* editeng/qa/unit/core-test.cxx:
- Modify TestAutoCorrDoc::ChgAutoCorrWord() to iterate through all patterns,
instead of finishing at the first one.
* editeng/source/editeng/edtspell.cxx:
- Ditto for EdtAutoCorrDoc::ChgAutoCorrWord().
* sw/source/core/edit/acorrect.cxx:
- Ditto for SwAutoCorrDoc::ChgAutoCorrWord().
- SwAutoCorrDoc::ChgAutoCorrWord(): Remove old dead code for autocorrection
on text with redlines.
* sw/qa/extras/uiwriter/uiwriter6.cxx,
+sw/qa/extras/uiwriter/data/tdf158454.odt:
- Add unit test "testTdf158454".
Change-Id: I8fb4a628a977b79b0ed2f239fd3749f15823b5df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160160
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Copy a single world from the Impress bugdoc to Writer, number of
paragraph styles increase from 126 to 221, while only +0 or +1 are
expected.
It seems the problem is that the editeng doc of the shape refers to all
styles of the masterpage and we write the style table before the
content, so we export all styles to be on the safe side.
Fix the problem by iterating the paragraphs of the selection in the
"copy" (not "export") case, assuming that typically the selection
doesn't refer to all available styles in the document, and the number of
paragraphs in a shape is not a large amount.
An alternative would be to limit the style import on the RTF reading
side, but not producing those not needed styles in the first place looks
superior.
Change-Id: I43e4c542e530ff6422357a28399718e89fdbabe9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169251
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Word boundaries at the end of the paragraph are now correctly detected.
Sentence case is not applied without multi word selection in Writer anymore.
Change-Id: If6e2eeaa1ecca215d583e8f33364db466bf7c57d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166928
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Now words are selected if the cursor is positioned at the end of
the word. SENTENCE_CASE does not force sentence selection anymore.
Change-Id: I672352b2c18bb695004fd4eb0f20ae5fd7a0ac53
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164546
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Modified ImpEditEngine::CreateLines and ImpEditEngine::Paint
to wrap multiline fields (hyperlinks) to wrap better:
Multiline hyperlinks can start/end in the middle of a line.
like this:
text hyperlink-start
hyperlink-line2.....
hyperlink-end text
Start of the lines of the multiline hyperlinks now follow the line
start (for example if the 1. line has a bullet/indent, and the
2. line does not then the multiline hyperlink 2. line will start
where normal 2. line would start)
Changed the way how fields wrapped while editing.. (we didn't split
fields into lines, when its textbox is edited, but now we do)
This way it is more a WYSIWYG editor. (when we edit, we see what
we will get)
Changed the constant reference rLine to non-constant pointer
pLine, because this hack change the actual line to the next line
at the end of a muliline hyperlink, so the algotithm will
continue calculating with the next line, as if it would be still
the previous line.
Change-Id: I2c67f4ae1b86ee9c73f01ae0c045f02e56a09c1c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162503
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Commit ce53519f02 (cool#8023 editeng:
support HTML paste, 2024-01-24) added support for pasting HTML files
into Calc cells while editing, but this doesn't work when only a HTML
fragment is provided, without headers and footers.
The HTML code in ImpEditEngine::PasteText() was modeled after the
HTML_SIMPLE case, which is some custom format from MSIE and that
rejected the data in case the header didn't match, so the HTML case also
required a HTML header in the above commit, but this doesn't work for
HTML fragments.
Fix the problem by just dropping the header check in
ImpEditEngine::PasteText(), because that data already comes from the
text/html slot of the clipboard, so there is already indication about
the file format, even without the header. And without headers, it's
almost impossible to recognize if the HTML fragment is a HTML one or
not.
Note that this is the HTML paste when a cell edit is active, the normal
Calc HTML paste is a different codepath, in sc/.
Change-Id: I4d37d80f947880fe22051c5fe84dc6bbc257e108
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162927
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
editeng text (e.g. Writer shape text or Calc cell text edit) had working
plain text and RTF paste, but HTML paste was not working.
This is typically not noticed because desktop paste usually goes via
RTF, but it can be visible when a LOK client just puts the best format
on the clipboard, i.e. HTML is provided, but RTF is unavailable in the
browser and plain text is also not written to the LOK clipboard.
Fix the problem by connecting the existing ImpEditEngine::ReadHTML() to
the generic ImpEditEngine::PasteText(): this already worked for plain
text and RTF, but not for HTML.
Note that "SIMPLE_HTML" was already supported, but that's not really
HTML but some custom format that contains HTML, and it's claimed that MS
IE 4.0 produced this.
Change-Id: Ib41529c66d9bda30cc4ed5faca4a99274ae594d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162449
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Change operator[] for getRef(..) method, so instead of returning
a pointer, return a reference to ParaPortion instead. This also
needs changes to the code, because we now need to make sure before
hand that the ParaPortion is really available in the list and when
this is not possible or convenient, the change the call to use
existing "SafeGetObject" instead. Add "exists" to check if the
object is available in the ParaPortionList.
In addition add "lastIndex" method to return the index of the
last ParaPortion in the list (shortcut for Count() - 1).
Change-Id: Id52c38f996468af51c75d50185110ec8502169e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162071
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Don't use raw pointers, when it is possible to move the unique_ptr
around into another object that is responsible for the object's
ownership.
The ContentNode is either in a vector in the EditDoc class or it
is moved to the EditUndoDelContent class for the undo/redo action.
Those 2 classes are responsible for freeing the ContentNode.
Change-Id: I977d8e418947bb48781f23575d62420260025e57
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161480
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Move the constructors into class body, cleanup operators so they
use more standard class based operators and use default for !=
as it will just be a neagtion of ==.
Change-Id: I1b99db6c9a82468ab76091eb93a5f3641024c65b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161365
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Miklos Vajna