BitmapColor has a Color() operator. However, this is confusing and
tends to hide that the two classes aren't the same. I have converted this
to GetColor().
Change-Id: I0be2dcb3fc420e7be9c8d04330e7a3fe69a5412a
Reviewed-on: https://gerrit.libreoffice.org/48245
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
auto-rewrite with <https://gerrit.libreoffice.org/#/c/47798/> "Enable
loplugin:cstylecast for some more cases" plus
solenv/clang-format/reformat-formatted-files
Change-Id: Ib58b16600c97f8dab1b32d7e049c946ca82e660b
SvStream::ReadFloat already does that, and SvStream is initialised
to SvStreamEndian::LITTLE by default.
Change-Id: I5859e43014533bcebef9d4b8f0678c516193b92e
Insert constructor everywhere, except a couple places that apparently
want to compare GetMapUnit().
Change-Id: I1910deb60562e5e949203435e827057f70a3f988
which actually does nothing useful. Looks like it was originally
intended to be used to implement color profiles, but since nothing
has happened on that front since it was created, safe to say it never
will. Probably not the right place in the graphics stack to do it
anyhow.
Change-Id: I36990db4036e3b4b2b75261fc430028562a6dbd9
Reviewed-on: https://gerrit.libreoffice.org/43240
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reduce potential confusion with the global tools namespace. Will
hopefully make it possible to remove the annoying initial :: when
referring to the global tools namespace. Unless we have even more
tools subnamespaces somewhere.
Thorsten said it was OK.
Change-Id: Id088dfe8f4244cb79df9aa988995b31a1758c996
Reviewed-on: https://gerrit.libreoffice.org/42644
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
and the vast majority of translations is to the ui language so default
ctor with that arg
and now drop OModuleResourceClient
Change-Id: I3b85a560ffdfe5f019c2271ac56a5fe4a361522b
had to change the structure of the plugin considerably, was too messy to
structure it to do the calculations on a per-function basis
Change-Id: I4edee7735f726101105c607368124a08dba21086
Reviewed-on: https://gerrit.libreoffice.org/40516
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl
* all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string")
* ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching
MODULE .mo files
* UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui
goes from l10n target to normal one, so the res/lang.zips of UI files go away
* translation via Translation::get(hrc-define-key, imbued-std::locale)
* python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there
to keep finding the .hrc file uniform) so magic numbers can go away there
* java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation
mechanism
* en-US res files go away, their strings are now the .hrc keys in the source code
* remaining .res files are replaced by .mo files
* in .res/.ui-lang-zip files, the old scheme missing translations of strings
results in inserting the english original so something can be found, now the
standard fallback of using the english original from the source key is used, so
partial translations shrink dramatically in size
* extract .hrc strings with hrcex which backs onto
xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap
* extract .ui strings with uiex which backs onto
xgettext --add-comments --no-wrap
* qtz for gettext translations is generated at runtime as ascii-ified crc32 of
content + "|" + msgid
* [API CHANGE] remove deprecated binary .res resouce loader related uno apis
com::sun:⭐:resource::OfficeResourceLoader
com::sun:⭐:resource::XResourceBundleLoader
com::sun:⭐:resource::XResourceBundle
when translating strings via uno apis
com.sun.star.resource.StringResourceWithLocation
can continue to be used
Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
First steps to organize an importer that can read/interpret
wmf/emf/emf+ and deliver a primitive representation for
the content by parsing it. Use the same mechanisms as
already applied for Svg, so to reuse abilities to keep
original binary data to allow save again and embedding in
files and have an implemented replacement bitmap based
representation. For this, unify the used helper classes
to handle more than just Svg. For 1st try, add test code
and static bool switches
Change-Id: I6e0a82943541d811a8f8d65a84115569fcd8cee7
e.g. without hidpi this could probably be reproduced with
export SAL_USE_VCLPLUGIN=gtk3
export GDK_BACKEND=x11
export GDK_SCALE=2
and CppunitTest_cppcanvas_emfplus fails with 0x00ff00 instead of 0x00fe00
Change-Id: I1ecd7dce7703ed50fe396e007424a3ec4252d063
The EmfPlusBoundaryPointData object specifies a closed cardinal spline boundary for a gradient brush.
This data is starting point for displaying correctly gradients.
Change-Id: I91b01417c6dc00a04dabfc5a035afe9085999240
Reviewed-on: https://gerrit.libreoffice.org/37519
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
Now it's time to enable warnings, to track not implemented cases,
to have clear notification what is wrong with imported image.
Change-Id: Ic880a5b7df03e4a98d4700bebb3d0f6d77980505
Reviewed-on: https://gerrit.libreoffice.org/37407
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
On on EMF+ images generated by ChemDraw, some elements were not displayed.
After investigation, occurs that position of points was not read
properly in same cases. This commit fixes such cases.
Change-Id: I1d01d8defc41f4e437a669ef1268b8e33823cfc1
Reviewed-on: https://gerrit.libreoffice.org/37406
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
Tested-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
Based on observation of different EMF+ files (eg. exported by ChemDraw),
there is minimal value of line width.
This commit is fixing all such import issues.
Change-Id: I5c26a1b511363eb1e429bf770ad0f482b124ecb5
Reviewed-on: https://gerrit.libreoffice.org/37319
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
