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>
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
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>
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>
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>
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: I6534db60dcb23cb3daefb91d5f27579a690a9637
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161364
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
...now that warning about O[U]String vars that could be O[U]StringLiteral is no
longer useful
Change-Id: I389e72038171f28482049b41f6224257dd11f452
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157992
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This makes makes all the Test class methods contined in the
class definition body, so more readable and less noise for the
actual test definitions.
Change-Id: I3ea177f27aa868a396e537b1682ce91d93c1208e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157837
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
This change is not about speed improvements but diverse
preparations to make changes/reading/understanding easier.
It does not change speed AFAIK.
Added a global static debug-only counter to allow getting
an overview over number of all allocated SfxPoolItem's
and the still alloated ones at office shutdown. The values
are used in Application::~Application to make a short info
statement. It allows to be able to quickly detect if an
error in future changes may lead to memory losses - these
would show in dramaitically higher numbers then (hopefully)
immediately.
Moved SfxVoidItem to own source/header.
Added container library interface support to SfxItemSet,
adapted already some methods to use it - not all possible,
I will commit & get status from gerrit 1st if all still works
and then continue.
Changed INVALID_POOL_ITEM from -1 to use a global unique
incarnation of an isolated derivation from SfxPoolItem. It
allows to avoid the (-1) pointer hack. Since still just
pointers are compared it's not worse. NOTE: That way, more
'special' SfxPoolItem's may be used for more States - a
candidate is e.g. SfxVoidItem(0) which represents ::DISABLED
state -- unfortunately not only, it is also used (mainly for
UI stuff) with 'real' WhichIDs - hard to sort out, will have
to stay that way for now AFAIK.
Changed INVALID_POOL_ITEM stuff to use a static extern
incarnated item in combination with a inline method
to return it, called GetGlobalStaticInvalidItemInstance().
Isolated create/cleanup of a SfxPoolItem entry in
SfxItemSet to further modularize/simplify that. It is
currently from constructor & destructor but already shows
that PoolDefaults are handled differently - probably an
error. Still, for now, do no change in behaviour (yet).
Got regular 'killed by the Kill-Wrapper' messages from
gerrit, seems to have to do with UITest_sw_findReplace.
That python/c++ scripting stuff is hard to debug, but
finally I identified the problem has to do with
the INVALID_POOL_ITEM change. It was in
SfxItemSet::InvalidateAllItems() where still a (-1)
was used -> chaos in detecting invalid items.
Change-Id: I595e1f25ab660c35c4f2d19c233d1dfadfe25214
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155675
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Andrea Gelmini