Commit 3d7e168a2a (n#783638 DOCX import of
wp:inline's distT/B/L/R attributes, 2012-10-11) was about a picture that
had non-zero spacing in LO, but zero in Word. The hope was that the
problem is just that the value is not imported.
Then commit a88ac70840 (fdo#63685
wp:inline's distT/B/L/R is in EMU's, not twips, 2013-04-19) was about a
picture that had so large spacing that the picture become invisible.
Fixing the unit of the spacing value made the picture visible again.
What was missed is that this value is just stored in the doc model, but
layout in Word doesn't use it at all till the anchoring is as-char.
Given that in LO as-char anchoring supports real spacing, just don't
import these values to have the same layout. That's what the WW8 import
does, too.
Change-Id: I1244269e06c5d190e8340349ddc12ae7b0572a4d
All new entries I added to the formatting toolbar
(DiagramArea, DiagramWall, View3D, InsertMenuTitles,
DiagramAxisY, DiagramAxisX, DiagramAxisX)
other icons will come asap
Change-Id: Id4869e34500cc4c6587b703a0a9d345505679226
Reviewed-on: https://gerrit.libreoffice.org/16438
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
The original code used 15 elements for positions, the 'repaired' one
lost 10 of them.
Also, do not try to be too smart and be verbose, letting the compiler
perform optimizations
(regression from 1b0f7ee1e0)
Change-Id: I0a1bc22d1abab083292de17b091c8be872fcee24
Reviewed-on: https://gerrit.libreoffice.org/16169
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
modify this minimally and select all standard pages
selected in the slidesorted, unselect them afterwards
and loop over the selected ones.
This looks like it could do with a rework to disentangle
the master/standard pages stuff, but leave it as is in
this commit
Change-Id: Ifd01fe21c91e5e6b07b2d8bba0d85facadc25998
This was causing 'if you click in the "default style" combobox in writers
standard bar and press tab and press tab the next two combo boxes go "blue",
happens in gtk2, gtk3 and gen.' reported by Caolan.
Change-Id: I0d97a181a605088a0b8bb8043771eb56280521e0
Saving relative references of named expressions to OOXML never worked,
upon reload they pointed to a different position offset by the value of
the original base position. This at least saves positive relative
references correctly, while generating #REF! for negative offsets which
is slightly better than having them point to a wrong location and
silently calculate different values..
Also, this is a prerequisite for TableRef ThisRow references in named
expressions to be saved correctly in A1 notation, which results in a
relative row 0 value.
Change-Id: I3734f910794ceab4b9224b214ad11c64d1d18e67
Some icons in galaxy are available only via a fallback, while the other themes
can implement these icons directly; but they did not end up in the
images_*.zip.
Change-Id: Ifc937ebec7a1e38828672e65706150f50abe8703
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>, modifying the patch to
carefully keep the undefined behavior in the already existing additions that may
potentially overflow, instead of making the static_cast<sal_Int32> introduction
look like end - pData->buffer will be guaranteed to fit into sal_Int32 (which it
is not).
Change-Id: Id2fb64dc4585dae34257be6968a8905254a3b42d
In the paints, we must use the size of the Window for the computations, not of
the RenderContext - the RenderContext can be much bigger than the Window in
the double-buffering case.
Fixes for example the list boxes, and many others.
Change-Id: I4c7607569f88b2d097587140858d0862e54b5ea6
just to get their mapunit or set visual size.
Will have to try something different here apparently
This reverts commit 757f461ef1.
(cherry picked from commit f2b3519c6b2aceacbe2fd9d53eb52dd36a356ecc)
Otherwise we are painting according to the rendercontext size in the
double-buffered case.
This fixes the rendering of the image in the startcenter.
Change-Id: I2630137c5d176d818bc1a68a970a9e5256ace97c
Writer doesn't support foot or endnotes in TextFrames, so they are not
supported in OOXML floattables, either. In the past, floattables were
imported as normal tables, that's how this worked. Restore the old
situation till the core limitation is there, so we at least don't
regress.
Change-Id: I4eb62617e3131176f7371e9ca69f11bc9e948a0b
This was always wrong for OOXML export, function names may have been
written without _xlfn. prefix or substitutions not been processed, but
will be vital for TableRef transformation to A1 notation.
Change-Id: Ieffd7d78e2c744d3c12228a0a815b5ce68b26c81
