WIth rotaiton being allowed the handle visualisation may be
dependent on this, so it is necessary to refresh their
visualisation on rotation chnage, e.g. for crop handles
Change-Id: I218e326894999381fc4058b7eba432491a0cf23b
The FlyFrame which may contain a Graphic needs working Crop,
interactive and in core. Adapted this to work with now possible
rotation, changed common code in svx which has to handle cases
for Draw/Impress/Calc and Writer differently. Tried to use as
much in common as possible. Additionally furter adaptions
to rotation itself.
Change-Id: Ia961e9490e2627c74220b186116f5aa4fcabca78
This version allows rotation (in 10th degrees) and perserves
it over save/load cycles. Rotation of multiples of 90 degree
behave close to original except not changing the contained
Graphic and being adaptable to all kinds of graphic. The
rotated Graphic is displayed centered and under preserved
AspectRatio in the available frame space (so no rotation,
180 degree is identical, 90/-90 is identical with 1:1 ratio
of the graphic)
Change-Id: I54b3385f709ee0d34a55324aca919dcd2ce0c009
To allow free rotation of Graphic FlyFrames in Writer,
several adaptions are necessary. This change takes care
of all needed changes to internally support a freely
definable rotation angle for that case. Save/Load round
trip is working, the graphic does no longer get modified
and added in 90-degree-changed state to the object, the
original will be preserved. Support for needed slot in
core/ui is implemented. Rotation can be applied from
Menus/Toolbars in the known 90/180 degree steps. Added
a slot/Button/command to reset rotation in these cases.
Added support in Sidebar to rotate using the rotation
wheel and/or numeric field. These fields and support added
to Image TabPage, too, fully functional.
Missing now is a solution for displaying the rotated
Graphic. For now, it just gets rotated, but this will not
be the final state of this change.
Change-Id: I6f3b85ebb5be2b4ad3311c536d54f27a37a494e7
RotGrfFlyFrame: Linux build adaptions
Change-Id: I365287ecd6525b1972e8436d61332f7121d88649
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>
To allow using the prepared VectorData of imported
Metafiles (and EMF+), let Writer use a Primitive
Renderer for Graphic output. For now, use a temp
PrimitiveRenderer (until sw is fully adapted to
primitives).
Change-Id: Iaa39111c5ef35a052394be6e4d1b86a5a8e33068
Reviewed-on: https://gerrit.libreoffice.org/41411
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
* 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
In case the intention is that the clip rectangle should include the
page, except a fly frame, we built a list of rectangles that covered
this area. This introduces the problem if adjacent rectangles don't join
perfectly.
Instead allow lcl_SubtractFlys() to work on a clip state directly, this
way the clip polypolygon will only contain two paths (the page rectangle
and the rectangle of the fly), so rounding errors can't happen.
Change-Id: I5b2e9a382aa7d16f3b16509670de754b5e00bd6d
Reviewed-on: https://gerrit.libreoffice.org/38066
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
change various ResId classes that use conversion operator to OUString to
functions that return a OUString
drop various defines
drop unnecessary toString calls
Change-Id: Ibeccdf2b91a46a2ed5b4b74e6024e301a023bc92
Reviewed-on: https://gerrit.libreoffice.org/37817
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Mostly generated using
make check COMPILER_EXTERNAL_TOOL=1 CCACHE_PREFIX=clang-rename-wrapper RENAME_ARGS="-qualified-name=Rectangle -new-name=tools::Rectangle"
Except some modules have their own foo::tools namespace, so there have
to use ::tools::Rectangle. This commit just moves the class from the
global namespace, it does not update pre/postwin.h yet.
Change-Id: I42b2de3c6f769fcf28cfe086f98eb31e42a305f2
Reviewed-on: https://gerrit.libreoffice.org/35923
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
we (very irritatingly) create dashed lines by creating a sequence
of dash drawing layer objects, so if its hugely long we create a hugely
long sequence
Change-Id: I38a0c6052cf058d5e02ebef7dd6a90e27f6e5454
Reviewed-on: https://gerrit.libreoffice.org/35781
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
regression from commit e598ab0447
very aggressively forced a new frame size via compat setting
CLIPPED_PICTURES on any fly - not just images.
This only affects MS-format documents, EXCEPT that it is a document
property, so if the file every spent any part of it's life in MS-format,
it will always retain that compatibility setting. That explains
why the problem was intermittent for me - and was hard to reproduce
in a clean document, even though I'd seen it in .ODTs.
bIgnoreLine (ignore the fact that there is no visible line)
was a confusing word choice for "if there is no line,
then return a spacing size of zero". bEvenIfNoLine=false is better.
Change-Id: I50a3bdef3a67339ae517ee6319920651bc56f9be
Reviewed-on: https://gerrit.libreoffice.org/30585
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
Generating primitives for chart visualisation can be moved to a
paralell executed task that loads the chart, thus speeding up
initial visualization. This is not possible for e.g. PDF or print
targets, only for edit visualization. On fallback, the replacement
images of the charts are used which are metafiles and have less
quality as primitives, but load quicker.
Change-Id: I68caa9e1bec50832bce535b5f54633d53cdef037
If OLE is a chart, buffer the primitives used for presentation as
info at the SwOLEObj, after getting them the first time using the
ChartHelper.
Change-Id: I6d7486185f6eac450de9328d37ea800f424f351b
...which (in LIBO_INTERNAL_ONLY) for Clang expands to [[clang::fallthrough]] in
preparation of enabling -Wimplicit-fallthrough. (This is only relevant for
C++11, as neither C nor old C++ has a way to annotate intended fallthroughs.)
Could use BOOST_FALLTHROUGH instead of introducing our own SAL_FALLTHROUGH, but
that would require adding back in dependencies on boost_headers to many
libraries where we carefully removed any remaining Boost dependencies only
recently. (At least make SAL_FALLTHROUGH strictly LIBO_INTERNAL_ONLY, so its
future evolution will not have any impact on the stable URE interface.) C++17
will have a proper [[fallthroug]], eventually removing the need for a macro
altogether.
Change-Id: I342a7610a107db7d7a344ea9cbddfd9714d7e9ca
when used as a mutable data-structure. Plain std::vector halves the time
taken to display the chart dialog
Create a class to represent the std::vector we are going to be passing
around, and move some of the utility methods into it to make the code
prettier.
Also create an optimised append(&&) method for the common case of
appending small temporaries.
Change-Id: I7f5b43fb4a8a84e40e6a52fcb7e9f974091b4485
This commit renames the most annoying abbreviations in Writer (and
partially in the shared code too).
Change-Id: I77e5134f42f25e3786afa36b7a505c7e3237a9e8
One tricky part is that in generic SwFrm methods SwRootFrm may not have
a shell and doesn't need a vcl::RenderContext, either; so check for that
situation explicitly where the frame may be a root one.
Change-Id: I48f39fb7195290393fca34f75d8798fb5f960f46
If the caller has a vcl::RenderContext already, use it. Otherwise just
use GetOut() on the shell in the caller for now.
Change-Id: I8070dd3d6622d211885067514d6eb728716830ee
