| Age | Commit message (Collapse) | Author |
|---|
|
bugfix tdf#68963 marked all __refheading__ bookmarks at TOC, but
those crossreferences were deleted if they are not recorded in
aReferencedTOCBookmarks. Redesigned the fix to include _Toc in the
crossreference name that is auto-generated, which is how MSWord
differentiates the markers.
Updated the test document to include even more combinations of
cross-references and numbered heading references.
Change-Id: I3d60d2b528ebfa1ffb108bbfc9e7db2c604af49b
Reviewed-on: https://gerrit.libreoffice.org/14822
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
LibreOffice recognizes MS Office Table Of Contents, but LO files
saved as .doc didn't show the Cross-Refence heading - it was blank.
Now bookmarks using the LO naming convention are also imported
as TOC bookmarks from .doc files.
Testcase included.
Change-Id: Icae5c0de31856ccc75ede9a97c0ea046dd97325f
Reviewed-on: https://gerrit.libreoffice.org/14018
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
RemoveFollowFlowLine() marks the layout invalid, but the
next cycle through does everything exactly the same again.
Try the same foul horror as nUnSplitted. But at least with
a test-case that nails down reproducing the bug if a better
fix is needed.
Change-Id: Id6698bcb2364bd0253bedd4a7c313e25f705be8d
|
|
MSWord, unlike Writer, can anchor even to a page break (i.e. after the last
paragraph). When this document was read, what happended was:
- the last paragraph was read and the current position PaM was set to point
after it
- frame was read and anchored to the PaM
- page break was read, making everything following be moved to the next page;
including whatever ended up at the PaM position
Handle this by checking for this case and inserting an extra empty paragraph
before the break. This shouldn't affect layout of the page itself anyway,
since the break should leave room for it (and MSWord shows a page break
there if control characters are enabled, so there is room).
Change-Id: Ia2a13bf5cf1c959b5aa228254365019a00a22679
|
|
Change-Id: Iec785ae538de81325812b1e6fe33115789b39770
|
|
This is similar to what writerfilter does. MSWord can have one page with several
different margins, which are saved using continuous sections, which causes all
kinds of trouble, because either we treat them as Writer sections, which means
we lose some of the data, or we treat them as Writer page styles, which causes
spurious page breaks if in the wrong place. Either option has its problems, but
here it seems slightly better to go for keeping the data and hoping the page
break will be in a place where a break will be anyway.
Change-Id: I8f52aa820750da6788ea04180a15ac334f6bf87b
|
|
Change-Id: Ic6e75cc2cedb61754b45bc4678a1185f580d5ed6
|
|
Honour the "different odd & even pages" header/footer setting from the
doc file even if there is no content for an even page header or footer.
Conflicts:
sw/qa/extras/ww8import/ww8import.cxx
Reviewed on:
https://gerrit.libreoffice.org/10191
Change-Id: I963f7f7189e399b1d859db0788fbfd291e868c54
|
|
These black rectangles are character shadows, because checking
whether there is a border at all was missing. In Word there
is no shadow without a border.
Change-Id: Ib3cb4e904fdd33f215c81d7c02762a196f484b1b
|
|
The LO page style needs page headers to be turned on if the
corresponding .doc file section has a left (=even) page header or a
first page header.
However this should not be triggered in the case where a first page
header is present but hidden due to the "different first page" header
option being disabled. This case is fixed by this commit.
Change-Id: If3de0df45378587fdbdecc6a091d2f4b60940b43
Reviewed-on: https://gerrit.libreoffice.org/10100
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
The reason the section ended up with incorrect margins was because
that is computed as 'page margin' - 'section offset', and the order
of setting these up was backwards: First InsertSection() created
the section using the page margin of the old page, and only afterwards
SetSwFmtPageDesc() set the page margin that should be used.
Change-Id: I18ddcb0b5928879a2297b6caca766eab979abd45
|
|
A vert orient position was already handled in case a floating table was
imported as a TextFrame, but in case we didn't do that, the vert orient
position was simply lost.
Fix this by importing it as the upper margin of the table (assuming that
the position is relative from the anchor position).
Change-Id: I3e96f3068605fd6313dfb3e55483e1bce6c063a5
|
|
For commits 1139d618b8bc6ab823a96184bd0f0257980aad24 and
893fe88469dec5b727d96f8ea1b4edb9e88288a7 .
Change-Id: Ia59ec5c4226944280c4b585c87179d28303bda4b
|
|
Change-Id: I91f6e861f6d0dbea1b57ac73857e0c706b27f681
|
|
Word supports formatting the paragraph parker itself, and we import that
as a formatting at a position after the last character (e.g. "foo" will
have that formatting at char pos 3, which is ignored by the layout).
In addition to this hack, commit
1c22545edf9085b9f2656ca92781158b6b123db3 (Fix issue #i119405: Numbering
text style changed after importing the *.doc, 2012-08-24) added a
SwTxtNode::TryCharSetExpandToNum() hack to Writer core, where in case
such a paragraph marker attribute is set, and the SwTxtNode has a
numbering, then also modify the associated character style as well.
As that commit already noticed, there are attributes which should not be
propagated to that character style. Extend this blacklist to ignore
RES_CHRATR_BACKGROUND as well, as Word does.
Change-Id: Idcb40d37d8688c76fbd61f28428f6e3bc995f799
|
|
This test exercises the import component of commit
ad51d4952dc30e0d1cdcc6037556cd7c66a61542 which adds support for full
colour borders in .doc import/export.
Also this test showed that page border import was not actually covered
by ad51d4952dc30e0d1cdcc6037556cd7c66a61542, so that omission is fixed
here.
Change-Id: I6272e9b22415b5af012145e99360c5765d5aec60
Reviewed-on: https://gerrit.libreoffice.org/8759
Tested-by: Michael Stahl <mstahl@redhat.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Reading the spec, it seems that we have two cases here:
- if lKeyProtDoc is set and fProtEnabled is 1, then editing forms is
allowed
- if lKeyProtDoc is set, but fProtEnabled is 0, then the document is
totally read-only
So in the first case avoid the SetModifyPasswordHash() call to allow
form field editing.
Change-Id: Id0c48e8eb4bde75c5520a7b108fcfada51148faf
|
|
Otherwise characters unhandled by our OpenSymbol font (like Arabic 0-9
numbers) won't be rendered using an other font, as no other font
provides the symbol charset. Do this in
SwWW8ImplReader::GetFontParams(), where we already have font name ->
font family mappings for a few well-known fonts.
The DOCX filter does the same for quite some time, and that's how Arabic
numbers in text using the Symbol font were rendered, instead of little
rectangles.
Change-Id: Ib794cac19ad7b073e39f3cbd7d4bad3994151c14
|
|
In general we're overwriting styles on import in case we're not pasting.
But these WW8Num* character styles are in general not from the document,
they are created because Writer needs a character style for each
numbering level to handle what's in the DOC file.
So, in case there is a character style with the same name as our
"character style for numbering" styles, prefer the later ones, as that's
intended most likely.
Change-Id: I675f867722360aca765bb96b0b43ea47deab9847
|
|
Change-Id: I2d31da5d659edcbebc682d5604d2db24b5e341fb
|
|
Change-Id: I6f6726dd99a3f894ae86de279c74270e19b49d0e
|
|
Commit 542a0d7260e4767d8aff839eb593e748a82ced48 (#100044# Cleanup for
optimization defines->enums, 2002-08-14) added the problematic "else"
without mentioning the reason, so I assume it's safe to just revert that
part.
Change-Id: Id90fbdfb1116be458a76c9653fec0633edc34fac
|
|
.. paragraph style
The original problem (from a user's point of view) was that the second
level of the numbering started from 1.1 instead of 2.1 in the bugdoc.
This was fixed by using outline numbering for level 2 as well, but this
is problematic in many cases: we want to have outline numbering exactly
when outline numbering is enabled for the given paragraph style.
So revert the change in SwWW8ImplReader::SetStylesList() and fix it
differently: SwWW8ImplReader::RegisterNumFmtOnStyle() explicitly ignores
list style if outline numbering is available with no good reason. Both
the WW8 format and Writer core allows to have outline numbering and a
list style at the same time, so set list style even when outline
numbering is available. This fixes the original issue, too -- without
introducing nasty fake outline numbering usage.
Also add a testcase for the original issue.
(regression from e3d5c3e0746916c4056389dd8c2daa6c451c8f6e)
Change-Id: Id7d2d67a96a858aee3230110cb518fea51d19d38
|
|
The problem was that the first page SwFmtHeader / SwFmtFooter wasn't
created in case the header/footer text was empty, even if fTitlePage was
set.
Change-Id: I5e58419161bcc663e2beb0338b95877469e0fd3c
|
|
Regression from 1e113cb7604e1509e7d598a9be329f1f7b6e9322. According to
the spec (see 2.9.181), the first bit disables border of "all but first"
pages, the second bit disables the border of first pages.
Change-Id: Ie49c9b7b76d34c2a93350481965790976f49d7df
|
|
This always worked, but I almost broke it with
8fe8bd6c3b5b1a539b7370f8c457fa69c061d2de.
Change-Id: I6b7817830da23afea758d1eb90395aeb01e32f67
|
|
Make sure that at least full-page-width multi-page floating tables are
imported on multiple pages.
Change-Id: Ifb974d50c50b1495634ac2652a3ae46235bb5f52
|
|
Change-Id: I4905fb384694c3f1dadccc6d8513c9a050e3f67b
|
|
Change-Id: I3e2928922ebcec8188c1b5416108373c4f26dd62
|
|
Change-Id: I705fc507429c5516e88597bd4db9e2e3dead8d93
|
|
odfimport sounds much better as there's no such thing as "odftok"
Change-Id: I0a8684377c257f2c40a2e8255f62343d4ff2272a
|
