This is a longstanding (at least since 2000: already present in commit
7b0b5cdf) error where left border linespace was used when calculating
right margin. It was copypasted from ww8 import to ooxml code verbatim.
The problem only manifests itself when left and right border spacings
are not the same; and since we had other errors in the borders import,
that additional problem simply wasn't apparent.
Also use scaled border width in border distance/margin calculations.
Unit tests updated.
Change-Id: I70961e1bde29471def69e1ef944ba2779cffe307
Reviewed-on: https://gerrit.libreoffice.org/51474
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
DOCX part was done in fb959e581c.
This commit fixes DOC part. Line width wasn't taken into account on
import; and export was done only with "from text" distance, which
gave poor interoperability with Word, where the borders were close
to page edge.
The common code is moved to editeng/source/items/frmitems.cxx and
include/editeng/boxitem.hxx.
Change-Id: I3d1d1312cb9dc9a9e00d9847ec11234cd787df60
Reviewed-on: https://gerrit.libreoffice.org/51366
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
UBSan build started to fail CppunitTest_sw_ooxmlexport8 with
> /include/tools/color.hxx:59:27: runtime error: value 258.5 is outside the range of representable values of type 'unsigned char'
> #0 0x2ad219182418 in Color::Color(basegfx::BColor const&) /include/tools/color.hxx:59:27
> #1 0x2ad219175e48 in (anonymous namespace)::lcl_compute3DColor(Color, int, int, int) /editeng/source/items/borderline.cxx:50:16
> #2 0x2ad219175574 in editeng::SvxBorderLine::threeDLightColor(Color) /editeng/source/items/borderline.cxx:77:12
> #3 0x2ad21917ea78 in editeng::SvxBorderLine::GetColorOut(bool) const /editeng/source/items/borderline.cxx:573:23
where lcl_compute3DColor had been called with (aMain=rgba(255, 255, 255, 255),
nLight=3, nMedium=40, nDark=83)
Change-Id: I0f4569d9fd9f54164efe395960bcc8a6840e7744
Reviewed-on: https://gerrit.libreoffice.org/51351
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
This is preparing to change how GraphicManager works where it
won't base itself around GraphicObject anymore but Graphic. No
functional or cosmetic change was made to the classes, only
changes that were needed because of the move and rename.
The only thing that wasn't moved is the GraphicRenderer as it
is not needed in vcl for now (but makes sense to move it in the
future to keep graphic stuff together).
grfmgr was renamed to GraphicObject as the GraphicManager will be
changed a lot and most likely moved out, so the name grfmgr won't
make any sense anymore.
All the UNO implementations were renamed with a prefix Uno and
used the same name as the class name. This is made to be more
specific which are the Uno objects (for example graphic.cxx
contained the implementation of XGraphic, which is similar to
graph.cxx contains Graphic).
Change-Id: I54a2fa6c7e997469aaa7770db05244adb9f64137
Reviewed-on: https://gerrit.libreoffice.org/51068
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Similar to commit 270d6db63d which fixed
the same issue in Writer. Surely having two text engines duplicating the
same bugs sounded like a brilliant idea to someone.
Change-Id: If85315fb00a2c0be78d502df0bfb9b50d9191368
Reviewed-on: https://gerrit.libreoffice.org/50921
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
using
git grep -lwP "Color\s*\(\s*(COL_\w+)\s*\)"
| xargs perl -pi -e "s/Color\s*\(\s*(COL_\w+)\s*\)//g"
and then some manual fixup where the resulting expression no longer
compiled
Change-Id: I0e268d78611c3be40bba9f60ecfdc087a36c0df4
Reviewed-on: https://gerrit.libreoffice.org/50372
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Translated the enum values in editeng, but kept the their translation
references in editrids.hrc, to prevent a need to update translations.
"UPPERCASE" was used instead of "CAPS", in alignment to style::CaseMap.
The values in svxitems.sdi don't seem to be used anywhere, but
translated anyway.
Change-Id: I1b3a9a68ce814841819b361ce5767764e3b1968c
Reviewed-on: https://gerrit.libreoffice.org/50305
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
When changing to use "GraphicBitmap" property instead of
"ImageURL", the import wasn't adapted and there was no test which
would warn of such an situation. This also changes the difference
between writer and impress where impress used "Graphic" and not
"GraphicBitmap" property.
Also adds missing tests for both writer and impress
Change-Id: Ieed629d2d37f7806d63e729b6ef23cd848593071
Reviewed-on: https://gerrit.libreoffice.org/50140
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Call drawing also after the new selection is set, similar to
other cases where DrawSelectionXOR() is called before and after
selection change.
In desktop LO drawing is always called again and again by timeout,
so there the selection is updated anyway, while in LO online painting
does not emit a notification.
Change-Id: I6e9337fc0cfb61656387ba44d901521c3dfa60dd
Reviewed-on: https://gerrit.libreoffice.org/50268
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
just the straight-forward MessageDialog cases first
a) remove border_width from message dialog .ui so as to take
the default border width
b) retain 12 as default message dialog border for vcl widget case
c) remove layour_style from message dialog button boxes so as to
take the default mode (a no-op for vcl widget case)
d) use gtk response ids (vcl builder will converts to vcl ones)
Change-Id: I7de281093a1b64f92f71ca11e7cbba42bb658154
Reviewed-on: https://gerrit.libreoffice.org/50143
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
* Add HoriAlignIgnoreTrailingWhitespace compatibility option.
** For MSO file formats it is set to true
** For ODP format it's set to false by default
** The flag is saved to ODP format as user data if the document
comes from an MSO format.
Change-Id: Ie22233d33a25e605de46120bfc2195038dffd63c
Reviewed-on: https://gerrit.libreoffice.org/49889
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
The SvxFontHeightItem (12pt) is originally a character-level property on
the table cell (covering the whole cell text) but when the user sets the
font height of the cell,
sdr::properties::CellProperties::ItemSetChanged() will turn that into a
paragraph-level property. This is fine, except that this way the
property has unclear semantics when the user pastes single-paragraph
content into an existing paragraph. (Keep the old paragraph properties?
Use the new ones?)
The current behavior is that sd::View::OnEndPasteOrDrop() calls into
ContentAttribs::SetStyleSheet() at the end of the paste, which removes
paragraph-level formatting (giving visibility to the from-style 18pt
font height this way for the existing content), so both the old and the
new paragraph formatting is lost.
Improve the situation by copying these paragraph-level character
properties back to character-level before paste at the paste position
(so doc model is back to the state after load), that way font height and
similar properties are not removed by the on-end-paste handler.
Change-Id: I43d321dedcda6c0df9b009b9d99c3544f783473c
Reviewed-on: https://gerrit.libreoffice.org/49868
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
because I
(a) forgot to insert parentheses which changes the meaning of some expressions and
(b) I now use the AdjustFoo calls when changing unary operations, which reads much better
This reverts commit 2096aac8b9.
Change-Id: I4b5941c4119b95aaefb9180a0ca95a1dbb4ec317
Reviewed-on: https://gerrit.libreoffice.org/49844
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The ability to inspect the output from the editeng ODF export is useful,
but the test code no longer built as the used SfxMedium ctor is gone.
We don't really need a full SfxMedium, a simple SvFileStream is enough.
Change-Id: I9b8cead4b7ebd6d4c9461cdecf357c84e623d856
Reviewed-on: https://gerrit.libreoffice.org/49806
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
It's possible that an ODF document contains redlines that will be
deduplicated by CompressRedlines().
If that happens during some editing operation, then a SwRedline
will be deleted and the nodes array becomes smaller by at least 3
nodes; any Undo actions that were created prior to the operation
that called CompressRedlines() will store invalid node indexes now
and Undo will crash.
So presumably it's a precondition of editing operations
that CompressRedlines() is a no-op.
Interestingly CompressRedlines() is also called from
SwEditShell::Undo()/Redo().
Ensure it's a no-op later by calling CompressRedlines() immediately
after load.
(Hopefully this should also work for the Insert File case.)
Add a test too.
Change-Id: Iec8135cc60260ed5cfff05a196b5c92cc03265f9
Reviewed-on: https://gerrit.libreoffice.org/49721
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Szymon Kłos