Age | Commit message (Collapse) | Author |
|
... as downloaded from
https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
Change-Id: I7aee9c6e42aabc9e023ab9a2ec3880dbde940396
Reviewed-on: https://gerrit.libreoffice.org/8919
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: I64c88b007564d3ca7b4f4bd95a458fee6bda7854
|
|
Change-Id: Ie4f15c894c13fd52e1ee175381a1e62b33864d39
|
|
Change-Id: I0ee3f1553b4efa67701385de5c7fe32e5992b537
|
|
Change-Id: I1f4a18e7aa6288e147c7f4c3f17bb99f1f0df5c5
|
|
Change-Id: I92c54f61fe8608d788cc236956f4a5a58e20a7df
|
|
Project: help c78bb98ac5b6e8c434678c063fa1762a828833d5
|
|
Change-Id: Ia1729f570cc80a0375532da6478de9d58518556e
|
|
...so they fulfil all the relevant iterator requirements out of the box.
Change-Id: I2a47fa18ba31e9680a2b18285a1640baaf0da40b
|
|
Change-Id: I3fb8a4f2854fb034d6b184ee46c04e8a8d03ca6a
|
|
This test is already disabled on non-Linux, but it fails in case there
is no display to use. For now just disable it in that case.
Change-Id: I29c52e803a1fca5f2bdeeb655c573ad8fef622e8
|
|
Instead, act as if it was true on all platforms. Don't do XOR clipping on any
platform. Simpler code is better code, and XOR tricks are generally very much
out of fashion these days, I have been told. Didn't seem to have any visible
ill effects on Linux at least.
Change-Id: I6192006c77a4a81363ec7b3292f72d512d5e9b53
Reviewed-on: https://gerrit.libreoffice.org/8901
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
|
|
MSVC 2010 LTO triggers some bug in painting Writer documents;
unfortunately it's not possible to put a VCVER check in there to enable
LTO by default only for MSVC2012 because the compiler detection actually
uses the ENABLE_LTO value.
Change-Id: I29ecdd552d8a8bbd673a844e6bf0c938a98825c2
|
|
Change-Id: I7262f0114f3bde17d81e14e0813cc7906e73fceb
|
|
We didn't have EMF+ rendering testcases so far, let's see if it works
out to render into a bitmap and then just assert pixel position colors
there. It's better than nothing for missing shapes at least.
Change-Id: I2d1c63fef1127f69af7156ed6c99553845f77c9f
|
|
Change-Id: Ic720aa7b30bbe56d67e0b65f3e047ad3ae521a97
|
|
Compared to 4c8d29f4f26bfa30689b2b98414fe874225b9a2e, we do not have to
provide 0 to mark the end.
Change-Id: I3b9a3de61df48caf271cb06b27cf9cfa174dc4ed
|
|
OAuth2Handler is from libcmis
Change-Id: Ia1986d6df7ab45580c66b4e536c5882af41f357f
|
|
Problem Description:
- In LibreOffice, the index field flag '\f' was not
getting preserved after roundtrip as there was no
support for it.
- '\f' field flag is used for Specific Entry Type.
ex. In our case it is "Syn"
Implementation:
- Provided import & export support for Index field flag '\f'
and added UT for the same.
Change-Id: I97c2456dd73c8bdf89ab105f8cac71bf7e2ad164
Reviewed-on: https://gerrit.libreoffice.org/8839
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I9d6e9df0b686c61597aaa0e194ab321445671a20
|
|
Change-Id: Icd3b57c4ae3dd79f4e57b72f9b241f15060322cf
|
|
This has been removed because it was unused.
Change-Id: If8fdf87cec1cd5fb5ee1924396643b152e6f3431
|
|
Change-Id: I1b846e79c2fdd718b7c67f39cb67ca2916520cb3
|
|
Change-Id: Ifd6a9897e3ebf978968efed79a478fa72cebe51a
|
|
Change-Id: I7cdc9b13fe950222521cb937e928da27ee55e866
|
|
Change-Id: If60a02f42a64ac60fb5be1072bf34efcbfa3cc6b
|
|
Change-Id: Ie3cfd1427dfe668c4cf682efa1f728dea764d277
|
|
Change-Id: I4d4780bdd8491c00140babc7651fc80a711bcf20
|
|
GetNextGlyphs could only deal with 1 glyph at the time
and was recalculing a lot of thing while iterating on the glyphs
This is not just a performance issue.. the notiong of keeping
per run glyphs information will be useful to re-establish the
proper support of glyphs display positionning by SetDXArray()
which today is completely ignored, in favor or letting
CoreText spread the extra free space itself.
Change-Id: Ib267c3e490619b650d4149f4b15b5758802942ba
Reviewed-on: https://gerrit.libreoffice.org/8879
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
Change-Id: I8862c1aaf245796a475ce52bec6c8e9a32862bbd
Reviewed-on: https://gerrit.libreoffice.org/8841
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: Ife3e8e4b339b3e2cba3bc81e14f616d75c4f5ed0
|
|
Change-Id: Icf3cc0ece477a1370d6dbf609e6b121075b3b999
|
|
DrawGradient should check to see if the polygon is a rectangle before
adding the gradient to the metafile. If it's a rectangle, we are
currently unnecessarily adding XGRAD_SEQ_(BEGIN|END) comment records.
Change-Id: I38aef322469f45403ed105d971d7e1d1441ba6a0
|
|
OutputDevice::DrawGradient doesn't check to see if it's meant to be
drawing a grayscale gradient when it adds it into the OutputDevice
metafile. Now fixed.
Change-Id: I83cb5255c01901e33ca1f751e91e8a77292663e6
|
|
Change-Id: I160a760a13c8e5140d6df295a9dffd05cf5e7b81
|
|
The bounding rectangle actually comes from the polygon. Therefore, it's
not needed. Removed from the following functions in OutputDevice, et al
+ ClipAndDrawGradient
+ XORClipAndDrawGradient
+ ClipAndDrawGradientMetafile
Change-Id: I4a87edcddb8895871982f0448854e1c0854124bc
|
|
Change-Id: I937d83e8c219bb1b672ec0b8b40204d9b20c8317
|
|
Change-Id: I9eff260046a08890629b41188082f196d547c734
|
|
Change-Id: I955e0dd7253c19ef7d6dad1c663bbcfd27d2b511
|
|
Change-Id: Ibd42c70edbd8a5ca5eba34bcb92e801c8dc97ba0
|
|
Change-Id: I637e84ae7fa82f687eb3f05b3e24e236f0ba8e3c
|
|
Change-Id: I75a88c9fffb3d2d5c6c12e6df89ba85a8eb92d34
|
|
Change-Id: Ifeeed4216275f944e61579408c77ae38945e60fa
|
|
Change-Id: I17a9c275743208dcb90075b0cdbd40caae3ab642
|
|
1. Fix regression 8659d189ec04a - rect. gradients no longer do grayscale
In commit 8659d189ec04aca78c8ffff97fcca507ca0a9ec3 I swapped the passing
parameters going to ImplComplexGradient and ImplLinearGradient from
aGradient (the copy) to rGradient (the original which didn't have the
grayscale applied).
2. Fix regression 954d7ad4ea7 - grayscale applied at wrong time
In commit 954d7ad4ea7ec3746b0f0cd3f850a25e82b39c14 grayscale was applied
in DrawGradient (Rectangle &rRect...) after the gradient was written to
the metafile. I was attempting to bring it into line with what
DrawGradient (PolyPolygon &rPolyPoly...) does. However, it remains to be
seen if that's actually doing the right thing - so best to revert this
as in all likelihood I may have caused a regression with grayscaled
gradients
Change-Id: Id94549b3366adb8fcf3cddc59d30029579430a30
Reviewed-on: https://gerrit.libreoffice.org/8908
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
|
|
...unused ever since at least fd069bee7e57ad529c3c0974559fd2d84ec3151a "initial
import."
Change-Id: I6ec792b68ce6b13b1cf074d9719a23daf3356e66
|
|
...left over after 66e4540041f09b4e779d27190f0925479f74103b "aDataAvailableLink
in SfxMedium was never called."
Change-Id: If2cfcc27f2b26ea3c950c2da1c673df940d94773
|
|
some more investigation into why bare language
autocorrect files are accepted needed but this
is a reasonably safe backportable to 4-2 fix
Change-Id: Ia294219e3c9d98710c6727238cedc15b040b408d
|
|
Before, all selection was recklessly replaced when you clicked something
else than a scaling handle (or the like).
It caused bug 69157.
But now, you can still drag the frame by gripping the interior one.
Btw, that the timer did not correctly start was because of the return
statement in the prior state.
Signed-off-by: Lennard Wasserthal <Wasserthal@nefkom.net>
Conflicts:
sw/source/core/uibase/docvw/edtwin.cxx
Change-Id: I5e02cfb2d5fe9cdb9fd7f50d0c961dcc418fadd6
|
|
Change-Id: Id9e29dcaab64b0244b5c53abb48ac27253a11917
|