OUString::equalsIgnoreAsciiCaseAscii and compareToIgnoreAsciiCaseAscii
taking string_view are added as overloads, rather than replacements to
the variants taking const char*, because the latter have benefit when
the passed C-style string's length is unknown, because these variants
don't pre-calculate the length.
Change-Id: I2def689d7b7784212dc6cd6b8ae9ab1d42604079
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150272
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Adds initial support for style:overflow-behavior
According to OpenDocument-v1.3-part3 style:overflow-behavior can take
values of:
- "clip"
- "auto-create-new-frame"
This patch doesn't properly implement support "auto-create-new-frame",
only "clip".
If "clip" is set, TextClipVerticalOverflow is set to true, causing the
vertical overflowing text to be clipped.
"auto-create-new-frame" is treated the same as omitting the
style:overflow-behavior attribute, setting TextClipVerticalOverflow to
false.
Change-Id: Iea298f41fbf0cf18dc07f41788ba0b665515db8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150122
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
after I got it wrong in both the original commit
commit d15a6560bd
use more string_view
and in the attempted fix
commit dd41ea3ec1
fix for o3tl::equalsAscii
thanks to sberg for spotting that
Change-Id: Iff12879de823553b2623db48979e9a720302f2d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150240
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Also extend the SwCoreThemeTest with asserts for the LineStyles
for the example theme.
Change-Id: I72aa64345d39fea84544e39b0a37a22f3e6baa5d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149360
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
They use rtl_(u)str_valueOf(Float|Double), to fill the buffer, and
the latter use doubleToString, which creates an rtl_(u)String, copies
to the buffer, and releases the rtl_(u)String.
So instead just use the rtl_(u)String from rtl_math_doubleTo(U)String
directly. Even when the end result is not needed as O(U)String, this
would avoid an extra copy step. Also, this avoids separate
LIBO_INTERNAL_ONLY implementations.
Change-Id: Ib1d9ecebd7876dfff7dc758f89ee4c1536647a50
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150150
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Introduces editeng text property TextClipVerticalOverflow.
Which when set causes vertical text that is overflown out of a
frame/shape truncated. (Only when text isn't being edited)
This is implemented as two steps:
(if text overflows)
1 - Vertical adjust is forced to top.
(Forcing vert adjust to top isn't the desired behavior normally,
but good enough for a first cut I'd say.)
-> The desired behavior would be after the overflown text is
truncated, doing a vertical adjust (of center/bottom/top) on
that piece of text.
2 - ClipRange is set to the height of the frame/shape.
This appears to work with different text directions too (vertical
etc.).
Change-Id: I697715a7d28bde94a6650609b16505ffab92173f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150106
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Extends ThemeTest in sw with the use cases relevant for import of
FormatScheme into the model::Theme (as much as it is implemented
currently).
Change-Id: I888f64c24ba455913d688be256f095d9c298dc2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147693
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
This is the start of the change where oox::Theme is only a holder
of model::Theme and not a oox structure. This is probably the
easiest way how to refactor that. In this commit only prepare that
and make the code work the same as it did before.
Change-Id: I926a35fd0db383ddb182dc83b36411b2d40b8530
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147692
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Also change other cases to use the shared_ptr so there is no need
to do copies and replace some of docmodel/theme/Theme.hxximports
with forward declarations.
Change-Id: I4588cb25e05e5f3e535011fffb68a8075b05aecc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147691
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
eventtesting with input of fuzzed keystroke was a fairly nifty idea, but
I never did anything with it beyond an initial experimental run and its
cluttering up things so drop it now
Change-Id: I44571e3e33124f522374d7c6772b7a7e7721aa1d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150125
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Specifically in sd/source/core/annotations/Annotation.cxx
We seem to end up fixing leaks here often.
The current tools::JsonWriter API is just very hard to use correctly.
So rather return an OString, which is cheap to copy,
and push that down into the LOK code.
AFAIK that seems to end up requiring less code and less adhoc copying
of data (specifically the queueing code in init.cxx was creating
copies when converting to std::string).
Ideally, we could have some special API to avoid the new strdup()
calls in init.cxx, but not sure how to prevent other people
from accidentally using that.
Change-Id: Ia33437c1bfd9cc2d54dfb99914d1b72db20335f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149963
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
7.18.6.2 Media clip data
In the media clip data dictionary, the optional CT and Alt keys
(ISO 32000-1:2008, 13.2.4.2, Table 274) are required.
Presumably writing a potentially wrong hard-coded mime type here isn't
intended.
Change-Id: Ifa8ee199a4cf9ce83f410860d59b6c30475f80e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150050
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
.. at least for the most popular types, and do it automatically in
MediaItem::setURL().
This should work in practice in most cases and is much simpler than
adding some type detection or calling into platform dependent avmedia
backends.
Remove the parameter that was only ever set to
"application/vnd.sun.star.media" anyway, the same value that would be
used if it's missing.
Stop using that silly type for everything, only use it when guessing
fails.
In case an ODF document is loaded, it will use the mime type loaded from
the file (see setting of MediaMimeType in SdXMLPluginShapeContext) and
not guess it because that would require updating the entry in
manifest.xml as well.
Change-Id: I8ce29cf7425678ae11dda1d8c875be818f8623af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150049
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
veraPDF complains:
Specification: ISO 14289-1:2014, Clause: 7.18.4, Test number: 2
If the Form element omits a Role attribute (Table 348), it shall have
only one child: an object reference (14.7.4.3) identifying the widget
annotation per ISO 32000-1:2008, 14.8.4.5, Table 340.
LO forms produce both page content in an MCID and an /Annot, so Role is
needed.
Change-Id: Ic231931a7c35d8da37ca76e02d97501edb43347c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149626
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Adds a flag that when enabled (opt-in for both old and new documents) changes behaviour of NBSP to not be strictly fixed width.
This commit also implements this behaviour such that NBSP has always the width of a standard space (0x20) on the given line. This change is only noticeable when the paragraph is justified.
Lastly a tilde or a degree character is now shown in place of NBSP when nonprintable characters are enabled, since the gray field alone is not visible in many circumstances.
Change-Id: Iabb30b5930ced62691cc4304f60c5e6dc886ed61
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149576
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Moved the Gradient intensity handling to tooling since
it is also needed for TransparencyGradients. Added
missing use of GradientStepCount for transparency.
Change-Id: I63ae6683fa0131be7faadc8572e19f5c43bf27e3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149957
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Open the context menu for the `CommandEventId::ContextMenu`
command for the character table that is used in the special
characters dialog, so opening the context menu is not only
possible by right mouse click, but also using the keyboard
(by pressing the context menu button or Shift+F10).
Move the handling for the case where the context menu is activated
using the mouse from `SvxShowCharSet::MouseButtonDown`
to `SvxShowCharSet::Command`.
When the context menu is activated using the keyboard,
use the centre of the currently selected item for the
context menu position.
Adding support for opening the context menu for the
recently used and favorite characters further down
in the special characters dialog is independent of this
and would have to be added separately.
Change-Id: I55ef43708b95f5a90b06777a8aeb32a64609160d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149927
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The `maPosition` member was only used for the position
of the context menu. It was set before calling
`SvxShowCharSet::createContextMenu` and then only used
in there.
Pass the position directly as a parameter instead and
drop the extra member.
Change-Id: I7ba9ec60ffb993ca1269d86efeddbe0950ed7fbe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149926
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
As discussed in tdf#153806, insert the currently selected
character from the special characters dialog and close
the dialog when the return key is pressed on the
table of characters (either showing all characters
or just the search result).
Something similar should probably be done when the return
key is pressed with one of the recent characters or
favorite characters in the dialog having focus, but
that needs to be handled separately, possibly along
with the other remaining suggestions to improve keyboard
handling in the special characters dialog as discussed in
tdf#153806.
Change-Id: Iccc19e4808ddf6f15c32710f9bea931e46b046bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149920
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Mike Kaganski