...according to <https://github.com/westes/flex/blob/
83d5d1695a2ab1d69ea4d8e7df27146c644876fc/NEWS>. Its use is no longer allowed in
C++17, so will start to cause build failures once we restrict builds to at least
C++17. (The situation with gperf is similar, but instead of checking for a
minimal known-good version that no longer emits "register", we instead check for
it indirectly in configure.ac, by creating gperf-produced conftest.inc and
including that in the program used to test which -std= value to use. We could
have done something similar for flex, but creating suitable flex output for
inclusion might be more work than it was for the simple gperf case.)
Change-Id: I662c6795ea5fde1420d9712c0ec910c0cadbc350
Reviewed-on: https://gerrit.libreoffice.org/63713
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* Update helpcontent2 from branch 'master'
- tdf#121797 XHP extensions (Help part)
WIP. This is the Help part.
Extend the XML parser to include new incantations of the <paragraph>
tag, namely
<h1> to <h6>
<note>, <tip> and <warning>
Extension to the <item> tag:
<menuitem>, <input>, <literal>, <widget> and <keycode>
* removed test files
Change-Id: I2a473ee8772606f5e84bb02e651bccc6749598f4
Reviewed-on: https://gerrit.libreoffice.org/63954
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
This is the core part of the bug, and is WIP
Extend the XML parser to include new incantations of the <paragraph>
tag, namely
<h1> to <h6>
<note>, <tip> and <warning>
Extension to the <item> tag:
<menuitem>, <input>, <literal>, <widget> and <keycode>
Change-Id: Idaed321cc8756fa6bcf4fbc170982365ff33d4d7
Reviewed-on: https://gerrit.libreoffice.org/63955
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
* Update helpcontent2 from branch 'master'
- tdf#121736 initial Help pages for Python scripts
Work in progress, initial addition of help pages for python
scripts in LO.
Change-Id: Iee95b1340c821fdb08524fdedeca3817b0de1459
Reviewed-on: https://gerrit.libreoffice.org/64137
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
PathSettings::impl_storePath wants to be able to nil the Dictionaries
path in the old copy of properties
Change-Id: Id579914cfa8b459efce962d304e2f9d6185bd55f
Reviewed-on: https://gerrit.libreoffice.org/64115
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Currently the accept process document creates 0 connectors. Instead, it
creates empty custom shapes: this commit fixes the loop, so that only
one of them is created.
The whole purpose of the follow sibling axis is that N - 1 connectors
are created for N shapes, not N connectors.
Change-Id: I54244c7615b83f607ef53a4ff8d01d3c9594856e
Reviewed-on: https://gerrit.libreoffice.org/64122
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
We render these at apparently the same pixel size as normal images,
but the underlying canvas is larger so these then end up pixel-matching
the true underlying grid.
Change-Id: Ic4b749127e9c81da78d06b34d9f88c5635dc64b9
Reviewed-on: https://gerrit.libreoffice.org/64044
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
we need this to support reshowing dialog after an intermediate
range selection dialog executes
Change-Id: Ib6575e5d852bd1d29cc1a791a5dc2c19949b67a0
Reviewed-on: https://gerrit.libreoffice.org/64100
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
the old EvaluateAsInt method has been dropped as from current clang
Change-Id: Ie30d1547ad8de777badff4b380d2fc9fb261e8fe
Reviewed-on: https://gerrit.libreoffice.org/64107
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The way the iOS app is built (over in the online repo), any
"resources" to be included need to be copied into the
workdir/CustomTarget/ios folder.
Change-Id: Ibac15b03dc447d6649e03404fe9a68ef3b4881b9
as in ODT implementation of Google Docs, and as in DOCX
supporting basic requirements of creating digital and
professional print media. This patch fixes DOCX import
(tdf#121668) and it gives the required PDF export, too.
In the case of solid color, color gradient, hatching,
pattern and tiled bitmap (except stretched bitmap),
this patch removes the obsolete white border around
the text area, if the user modifies the page background.
Note: likely the white border was good for home printing
in former times, but now it forms only a serious
barrier for most users to create de facto design
standard whole page background formatting instead of
its unacceptable poor man's version.
Note 2: the OpenDocument standard refers XSL/CSS here,
and browsers adapt background settings to the body margin
area the same way, as Google Docs and fixed LibreOffice do.
More information:
tdf#112195 "(Whole-Page-Filling) - Allow page background to cover the
whole page (reloaded)"
tdf#33041 "Allow page background to cover the whole page, not only
within page borders/margins"
tdf#121668 "FILEOPEN DOCX Page Color created with Word disappears on the
margins"
ooo#9370 "Off-margin page background"
(https://bz.apache.org/ooo/show_bug.cgi?id=9370)
Change-Id: I7c6c96ceaf7102b38e3e5c1ed767db0ee63520ab
Reviewed-on: https://gerrit.libreoffice.org/63914
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
This allows us to choose to render HiDPI images at the right time,
when we have the DPI of the device to render to.
The first step in a better, and more industry standard way of
improving our UI for HiDPI via rendering level scaling that should
retain a consistent look across the app with many fewer changes.
Change-Id: I36681f3242cb650de4f0b2d0fcdffbe5618e30fc
Reviewed-on: https://gerrit.libreoffice.org/64040
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
With introduing String rotation support
I made mistake by not removing Maping from DX-Array.
With this commit I'm fixing that issue.
Now drawing with DrawDriverString record,
and rotation is working perfectly.
Change-Id: I7ae051b3791d9d2d8e2143ed33d21b7bfbc551c6
Reviewed-on: https://gerrit.libreoffice.org/64079
Tested-by: Jenkins
Reviewed-by: Patrick Jaap <patrick.jaap@tu-dresden.de>
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
This change solves the non-linear World-To-View trans-
formation that calc uses due to it's screen rendering
as good as currently possible (AFAIK).
Calcv view is layouted on pixel base (due to better
homogen distances and full pixel lines between cells),
but this leads to having a non-linear transformation
between discrete units (pixels, view) and model coordinates
(World). In principle, each cell has it's own (so called)
ViewTransformation -> the position on screen depends on
the mappings of all cells top/left from it. This is
obvioulsly non-linear and can sometimes be seen by
producing 'offset' errors when many cells (small and thin)
are shown in low zoom stages.
No better solution for this comes to mind easily. The
extremes are - on the one hand AntiAliasing the whole
calc edit view and accept 'unsharp/AAed' lines - on the
other hand what we have now.
Maybe a future solution could find a mapping that gets
close to linear mapping for the full view. On the long
run this state is hard to keep correct. Even with this
extended solution the mapping of SdrObjects spawning
mutiple cells is assumed 'linear' in that area - which
is in reality currently not the case (!)
Note: This is only true for the screen visualization,
print and/or PDF export do not do that pixel-based
layouting.
Note2: This mechanism is general in DrawingLayer (look
for '.*GridOffset.*'. If it is deactivated by providing
no offsets, the result is the unchanged, linear mapping.
First step: Add interfaces to get a possible GridOffset
at ViewObjectContact. There it belongs, we have a view-
dependent offset per object and view. Add mechanisms to
create on-demand and reach back to the view (aka calc's
derivation of it).
Second step: Implement the on-demand creation, adapt to
use it in ViewObjectContact::getPrimitive2DSequence, add
stuff to reset on zoom change, disable temporarily old
mechanism -> paint already works. Need to adapt the
places from old mechanism where the GridOffset was used,
but no longer the geometry creations.
Third step: Isolated and disabled old mechanism (by
already removing SetGridOffset). Marked all places that
possibly need change with '//Z' tag. Main work now will
be to adapt in the SdrView implementations in svx to know
about having a SdrObject-dependent ViewTransformation
at all (currently not known, was hard-coded at some places
from the old code, ViewTransformation set as MapMode at
a target OutputDevice, not member at SdrView at all...).
Fourth step: Adapt the Handles and OverlayObjects to
use an evtl. existing GridOffset. The mechanism is that
the SdrHdl(s) can be seen as 'Model-Objects', these get
converted to OverlayObjects in the ::CreateB2dIAObject()
implementations, for all SdrMarkView and SdrPageView,
so this is the place where the ObjectContact is known
(the SdrPageWindow *is* a ObjectContact) and the view-
dependent GridOffset can be calculated per SdrObject.
I modified OverlayObject to be able to work with a
set Offset that embeds the created visualization using
this additionally.
Handles get now correctly set and have a working HitTest
(due to that already using the primitives). Some inter-
action stuff already working, some will need more
adaption. We simply have no concept for this stuff...
Refactored to not get dependencies to SdrObject in
ObjectContact.
Fifth Step: Make HitTest work by adding the View-And-
Object dependent GridOffset in the View when HitTest
is triggered. This is in SdrMarkView::CheckSingleSdrObjectHit
where pObj->GetCurrentBoundRect() is used that gets the
view-independent form. To make HitTest work, add a possible
GridOffset.
Since this will be necessary more often in SdrView hierarchy,
added a tooling method (getPossibleGridOffsetForSdrObject)
at that level after checking that at that level will be
reachable at all potential spots.
Inside that method the correct ObjectContact will be identified
and the object-specific offset requested there.
Sixth Step: Adaptions and started some cleanups. Still some
adaptions needed:
- After creation of new object, need to relocate from
used GridOffset setting to WorldCoordinates
- Interactions, e.g. start with dragging handles or full
object/points
Seventh Step: React on EndCreateObj. Here, the created
SdrObject is in model coordinates and needs to be adapted
to evtl. GridOffset. This is 'tricky' due to calculating
the possible offset based on new coordinates 'close'
to the target position, but may be in the wrong cell.
Nonetheless this is the best we can do here.
Last (hopefully) missing are now all interaction
viszualizations. They already work and are applied
correctly, but wrong visualized.
Have taken the time to unify adding OverlayObjects for
selection visualization to OverlayManager, see
handleNewOverlayObject. This does all needed when adding
OverlayObjects in one place where the GridOffset can
also be handled. It makles things more safe - not possible
to forget one of the three steps for others.
Eighth Step: Do the same unification for creating the
OverlayGeometry, also rename methods to make usage more
clear. We now have
SdrHdl::insertNewlyCreatedOverlayObjectForSdrHdl
SdrDragMethod::insertNewlyCreatedOverlayObjectForSdrDragMethod
which can do the needed GridOffset changes centralized.
Needed to get a ObjectContact for this at SdrDragMethod,
so adapted ::CreateOverlayGeometry implementations
accordingly. Missing is now the implementation in
insertNewlyCreatedOverlayObjectForSdrDragMethod to add
the GridOffset - if used. This has no SdrObject at this
time, so we will need a fallback to do the same using a
Range (Rectangle). The stuff doing this for SdrObject
already has a fallback and is based on using the Rectangle
from the SdrObject anyways, so this will be possible.
Ninth Step: Cleanup of old stuff (no more //Z), adapted
some usages of OverlayObject creations to use
getViewIndependentPrimitive2DContainer instead of the
view dependent parts so that offset applied to
drag-overlays is correct and not already added. Adapted
insertNewlyCreatedOverlayObjectForSdrDragMethod to use
calculateGridOffsetForB2DRange. Use now that instead of
SdrObject-based approach in calc - is more generic.
Getting closer, but still not complete - there is an
error with dragging the grepped handle somehow - the
offset for drag is somehow wrong.
Tenth Step: Corrected that offset error. Of course at
interaction start and progress (move) the coordinates
are in GrifOffset coordinates and need to be corrected
to Model coordinates. Done that at ::BegDragObj and
::MovDragObj, works well.
Of course there are exceptions for the crop-handles, so
needed to add setting the correct parameters at SdrHdl
when these got created, then all works as expected.
The strategy is to *not* change the model data itself
in any way, instead do all changes/adaptions in the
view-only code. This has minimal impact and is needed
due to having a 1:n relationship between model and
views anyways.
There are two directions: All visualizations are adapted
to take the GridOffset into account (SdrObjects, overlay,
handles, InteractionObjects, ...). In the other direction
input like MousePosition is in principle in calc EditView
in 'GridOffset'-coordinates and needs to be mapped back
before usage.
Change-Id: I2ecdd409def96a7248a26a65a22e59eb962880a0
Reviewed-on: https://gerrit.libreoffice.org/64057
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
At least on tinderbox MacOSX-x86_64@49-TDF the sed appears to ignore the
literal newline character, which is unfortunate, particularly since it
worked on the Jenkins builder.
Blind fix to replace this with a tr invocation that already appears to
work in Zip.mk.
Change-Id: I7a77e69774b050a018b12c73ddd9eff849c33a86
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ice2eb8c5994bf2ccb88972332ca4a1d3ed41752a
Reviewed-on: https://gerrit.libreoffice.org/63826
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
