Surfaced after 6ea7ca4578
Change-Id: I4975f51a7a0ca73eccfd17338abc122254b57113
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125338
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Unicode 14, 5 new scripts, 12 new Unicode blocks.
In i18npool/qa/cppunit/test_breakiterator.cxx
TestBreakIterator::testLao() had to be disabled/adapted.
Needs to be investigated, see comments there.
As is, Lao script word break has regressions.
Correct UBLOCK_TANGUT_SUPPLEMENT Unicode range endpoint to
0x18D7F, see
https://www.unicode.org/versions/Unicode14.0.0/erratafixed.html
for which ublock_getCode(0x18D8F) now returned UBLOCK_NO_BLOCK and
thus luckily the assert in svx/source/dialog/charmap.cxx hit.
Change-Id: I4bad16ecfab3f44be365b8f884c57f34af68218e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125322
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
The scenario is that something scales a bitmap and then asks for it
to be drawn (possibly drawn scaled again). One example is
OutputDevice::DrawBitmap() subsampling the bitmap that according
to c0ce7ca488 is supposed to improve quality with headless(?)
backend, but with Skia it's pointless and it breaks things like
caching during repeated drawing, because then GetSkImage() will need
to generate a new SkImage each time.
Since Skia backend uses delayed scaling, these cases can be sorted
out by checking the stored SkImage and using it if suitable, as
the original image is as good as the rescaled one, but often
it's better - it may be cached, sometimes the scaling operations
cancel each other out (often the case in HiDPI mode).
Change-Id: I0af32f7abdf057a3bdda75247d2dc374eaf1bc4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125311
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
They are just a set of small functions, and I sometimes need
to debug optimized builds too.
Change-Id: I6350476e8c7fef85460a88b9e3d56d02213764ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125310
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
It turns out $(gb_SPACE) is not just one space.
Change-Id: I8f5cd13d14d71f0a6dd7d8b89ee857f983d27d20
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125309
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
35d248cab1 forgot to fix one place where
control characters were in a presumed XML declaration.
Another place looks missing where comments are handled, but it's not
clear if these can be passed on to Writer.
Revert the previous fix from commit
b3325ef8cd.
Change-Id: I11ad13de9122533626e512ce0384051e3e5bd97f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125306
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Importing an HTML file including an image conserves the aspect ratio in
Writer.
Change-Id: Ia31b36884daf2728b0989ae7c1e6ece683543d7b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125170
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
This fixes a LO 6.2 regression caused by
commit 4cf5a46f16.
Change-Id: I4aee8f4e79a40a8b8f82faa3e62dead80a952510
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125037
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
* Replaced multiplying by magic number 0.01745329251994 with
basegfx::deg2rad() which is equal to M_PI/180.0
* Instances of this could be found using:
git grep 0.01745329251994 *.cxx *.hxx
Change-Id: Ib813251f6223e4218fe977c0211732c22199295d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125294
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
ooxml supports theme colors and tint/shade value that additionally
changed the theme color. Read back which theme color + tint/shade
value was applied in the resulting color and add this attributes
as properties to be used by writer.
In sidebar theme panel the changing the theme colors now doesn't
takes this into account and changes the colors correctly.
[ Miklos: left out the Wrtier bits for now, focusing on Impress first. ]
(cherry picked from commit 16a0a2089e8572a35a36a7e649703893ecd06299,
from the feature/themesupport2 branch)
Change-Id: I8e0d62ec8c0534e603fb1e5fb000dcf84aea5da2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125304
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Reporter mentioned a bunch of missing colons across the UI.
Change-Id: I278d0ad7073fb399c979f0fc52adc306f51ae49d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125147
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
To support theme colors the SvxColorItem must be extended with
an optional attribute theme index to define the index to which
theme color current color belongs and an optional tint/shade
attribute define how much the color ha been additionally tinted
or shaded.
[ Miklos: left out the potentially breaking svx/sdi/svxitems.sdi
changes. ]
(cherry picked from commit ccdbf815e00dbe2ba21f7e86b6743df100b7401f,
from the feature/themesupport2 branch)
Change-Id: Ifb0481770be675181dafa94cd2778f374fcf3c7e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125296
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
* Update translations from branch 'master'
to a692f49808bffb7f402cd88cbf48e32b2044d111
- update translations for master
and force-fix errors using pocheck
Change-Id: I93c02cdd542eb2c42765f65e9e78f2dc8f339005
Since Skia is now the default on Mac too. Clang on Mac should
be the given, but check for consistency.
Change-Id: I490d5434374d98b1d7a219c2bca48747e31eecac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122337
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
This is a re-land of commit 2489edcbe0,
now that HiDPI support (tdf#144214) has been implemented properly.
Originally coming from the ESC decision from Aug 26th.
Change-Id: I4d397282adeeac50ff19ba651b920c73080d3dfd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125273
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
so the sizes and relative positions are invalid under gtk, unclip
the SysObj when using get_extents_relative_to
Change-Id: Ibdaff20531a2a40b3b9b7dc9ac880d014db07d5a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125272
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
weird this somehow sneaked out when converting custom animation
pane to sidebar when undoing other operations (delete etc.) stayed
in place
Change-Id: I6287682839d0e0401cc60bf82257d86765f3a858
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125110
Tested-by: Jenkins
Reviewed-by: Katarina Behrens <bubli@bubli.org>
Since the image will be actually eventually drawn twice as big,
cache an image that is twice as big.
Change-Id: Iea0340cd92c102e453330723c797659c742feb63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125263
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
It'll draw double-sized 1/4 of the content in the topleft corner
of windows, but it's still useful for some tests.
Change-Id: I20c6d2382d704ddcd67b8cb81eb7abf37b57a92f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125262
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
The basic idea is the same as the 'aqua' backend, simply set up
a scaling matrix for all drawing. That will take care of the basic
drawing everything twice as large, which is twice the resolution.
And then blit this data to the window, which expects data this way.
Converting back from backing surface needs explicit coordinate
conversions, and when converting to a bitmap the bitmap needs
to be scaled down in order to appear normally sized. Fortunately
I've already implemented delayed scaling, which means that if
the bitmap is drawn later again without any modifications, no
data would be lost (to be done in a follow-up commit).
Unittests occassionally need special handling, as such scaling
down to bitmap not being smoothed, because they expect exact
color values.
Change-Id: Ieadf2c3693f7c9676c31c7394d46299addf7880c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125060
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
