The Writer 'Heading 3' paragraph style is gray by default, but (just
like in case of DOCX) that shouldn't have any influence on the RTF
import result.
Fix this by moving the compat setting from the DOCX filter
implementation to the common dmapper.
Change-Id: I86c7cf1a66f82b438ce8379467773a88c9e229af
The document containing a custom table is getting crashed.
In the document the user has created his own costume table styles and
in the created custom table style the user has set repeat first row as header property.
The corresponding tag for this property is 'tblHeader'
LO was adding this property as a part of cellProperties in DomainMapperTableHandler.cxx.
But it is a part of a Row Property. That is why there was a crash @ open.
In DomainMapperTableHandler.cxx : 'endTableGetCellProperties' tblHeader property is removed from
style as it is not allowed for a cell.
Change-Id: I83cd369aa4497ec3f4b567174f23ddee9be2864e
Reviewed-on: https://gerrit.libreoffice.org/8848
Tested-by: David Tardon <dtardon@redhat.com>
Reviewed-by: David Tardon <dtardon@redhat.com>
Compared to 4c8d29f4f26bfa30689b2b98414fe874225b9a2e, we do not have to
provide 0 to mark the end.
Change-Id: I3b9a3de61df48caf271cb06b27cf9cfa174dc4ed
Problem Description:
- In LibreOffice, the index field flag '\f' was not
getting preserved after roundtrip as there was no
support for it.
- '\f' field flag is used for Specific Entry Type.
ex. In our case it is "Syn"
Implementation:
- Provided import & export support for Index field flag '\f'
and added UT for the same.
Change-Id: I97c2456dd73c8bdf89ab105f8cac71bf7e2ad164
Reviewed-on: https://gerrit.libreoffice.org/8839
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
This test exercises the *export* component of recent work to add support
for full colour borders in .doc import/export.
Change-Id: I2da0b8b488e399d0cd4791678fac6e1c85921c2c
Reviewed-on: https://gerrit.libreoffice.org/8887
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
- Earlier the table width was compared with the text area to decide if the
fly has to be created for the floating table.
- In most of the cases such floating tables were the ones which did not have
any text around them and not importing such tables as fly made sense.
- But there are some scenarios where in the floating tables have width
greater than the text area but are positioned in a way such that they begin
before left margin and end before the right margin moreover they appear to be
really floating (unlike in first scenario) as they have text around them since
there is still room for the text.
- Handled this scenario and added a UT.
Reviewed on:
https://gerrit.libreoffice.org/8840
Change-Id: I7ea25e04ed7c6315e4e4fe4b67badf451c30cd0c
Additionally add loading of HTML document and parsing the document
with libxml - to be able to assert with xpath expression.
Change-Id: I7c62082a124c3705626cd76c8a4cdabc16372399
Added a new export only macro - this can be used to create tests
which import a document (in any format), and export it in a format
that is being tested. The exported document isn't loaded again, but
it must be asserted using xpath. The primary usage of this is to
test the HTML export.
Change-Id: I1ad300f6274a2181f7f29fed3903b99b68f37fd9
Z-Index was not handledin LO for vml.
I have made the changes to handle that using aGrabBag.
Change-Id: I2af3b2974c8eb699bc6a7b743dc438584d6517ac
Reviewed-on: https://gerrit.libreoffice.org/8833
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
This scenario is not a valid one, Word doesn't handle it, either -- but
the old LO 3.4 parser did. So add minimal support for it to avoid
the regression.
Change-Id: Icc2e8d3bf314e9cadda57956668033aa6d092457
Issue:Only one AlternateContent is getting written in the RT file irrespective of
the number of TextBoxes in the original file which is causing the issue.
RootCause is found in DocxAttributeOutput::OutputFlyFrame_Impl where under case
sw::Frame::eTxtBox,m_aFramesOfParagraph.push_back(sw::Frame(rFrame)); is getting executed only once.
push_back should happen as many number of times as there are TextBoxes in the original file.
if(rFrame.GetFrmFmt().GetName() == m_aFramesOfParagraph[nIndex].GetFrmFmt().GetName())
bDuplicate = true;
In the above check both the GetName() are returning values as empty which leads to
bDuplicate equals TRUE and hence push_back does not happen.
I have introduced one more check to handle this.
Also changes are made in for loop to make it more efficient.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/8782
Change-Id: I397aa3c4548cb57e8dacbf3fbf9ebaf87c0daa80
Commit bbe3627eece0c3486e7ea11f2f13377aaa3a8fed (rtftok: stop sending
sprm:CRgFtc{0,1,2} tokens, 2014-03-05) dropped support for case when a
font name is used in multiple entries in the font table, but with
different encodings.
Turns out that this is a valid use-case, so revert back to the old
behavior where the key of the encoding table is the font index, not the
font name.
Change-Id: I048dff58af801d704fd4bc75a6a4dcb0f03bf185
Some table properties can be defined by the table style but cells can
overwrite them in their cell properties section. Our exporter was
writing all the cell properties in all cases, regardless of them
being defined by the theme or not, and we shouldn't do that if we
want the document to work properly in Word.
To fix the issue I store the style-defined cell properties (the
format of all four borders) in the table grab bag. The exporter
recovers them and compares with the cell properties before writing
them; if the cell property matches the stlye-defined one, we don't
write it to the document.
An existing unit test was slightly modified to check that the actual
cell properties are not being skipped.
Change-Id: I3aa12d76fb8f73d3fd300f254d19e1683fb6146c
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
The brush color contains both the color itself and transparency as well.
In case of DocxAttributeOutput::FormatBackground(), the sColor should
contain the color part, and oAlpha the transparency part.
In case of drawingML export of Writer TextFrames, an automatic color
(0xFFFFFFF) shouldn't be recognized as "auto", as that's invalid:
instead an explicit 0xFFFFFF with zero transparency should be written.
Fix the problem by calling msfilter::util::ConvertColor() for the RGB
color only.
Change-Id: I2132375a4dbcac1667aed49c74e581183178b0cc
Issue :
Numbered list without suffix does not get preserved after
Roudtrip.
Description :
- For level zero LO was writing w:lvlText with epmty value.
- This was because in DocxAttributeOutput::NumberingLevel()
check was based on empty NumberingString.
- But for "deciaml" also rNumberingString appears to be empty
for level-0
Implementation :
- Added check to write empty value for w:lvlText only if
NumberingType is "bullet" with level-0.
- This will not write empty w:lvlText with level-0 and
NumberingType as "decimal".
Reviewed on:
https://gerrit.libreoffice.org/8768
Change-Id: Ic6ece45e0122da05013beac93a6e11fac926514d
Table style is a property that defines a set of background and line
attributes for cells. These attributes depend on theme settings (e.g.
theme colors).
We added a grabbag to the table object to save the table style name.
We detect that name on export and write it back to the document.
Finally, modified an existing unit test to check this attribute too.
TODO: To get the table style working properly after a roundtrip, we
must preserve it and also check that its values are not being
overwritten by different cell or table properties.
Change-Id: Id0e022a389561960c21ab874db33649499735024
When some background color is set to a table cell, it is stored in the
cell properties tag <tcPr> like this:
<w:shd w:fill="ECD2B6" w:color="auto"
w:themeFill="accent6" w:themeFillTint="66" w:val="clear"/>
The theme-related attributes in w:shd were not being preserved. To
fix this I added an InteropGrabBag to the cell properties object,
which is filled with the attributes of w:shd to be checked on export.
The exporter checks if the cell color is still the original color that
was imported from the file, if it is not it means the user has
manually changed it during the edition and the new color is written
instead.
Finally, added a unit test for theme attributes on tables.
Change-Id: Ica8091b5eb4075e51912a255650a1d9d64f5767a
In the test file Table Grid had only one value for entire table width
while there are two cells in a table row. So the table was not
imported with the correct Column Separators.
Added fix to calculate column seperators from cell widths if
unable to calculate from Table Grid, and all the cells have individual cell widths and
there are no after and before cells.
Change-Id: I466737437a18d3373e75fea5ad56c9e31eb149ec
Reviewed-on: https://gerrit.libreoffice.org/8767
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
It appears that the C++ standard allows overriding destructors to be marked
"override," but at least some MSVC versions complain about it, so at least make
sure such destructors are explicitly marked "virtual."
Change-Id: I0e1cafa7584fd16ebdce61f569eae2373a71b0a1
In the past in case FillStyle was set, BackColor wasn't ignored, now it
is, since 6e61ecd09679a66060f932835622821d39e92f01 (Merge back branch
alg_writerframes to trunk, 2014-03-19).
The intention there was that in case FillStyle is set, FillColor will be
used: so to keep both new users and old filters happy, just restore
handling of BackColor in case FillStyle is set, but not FillColor.
Change-Id: Ie034a959e72e48b617cf598af8f7afd030bb50c4
Now that fill attributes are available in the item set of the shared
exporter, just had to adjust the WhichId of fill style / gradient fill,
and it's working again.
Change-Id: Iec7048ef77aea534a567799bfd385fcc029586b3
Fill attributes with their original WhichId are only used for frames at
the moment, replacing RES_BACKGROUND. To keep export filters working,
handle those fill attributes as frame ones as well.
Change-Id: I1e59b483b706d9fd3f9b947e83244740e3293f9e
Commit 6e61ecd09679a66060f932835622821d39e92f01 (Merge back branch
alg_writerframes to trunk, 2014-03-19) changed the sw UNO API, so that
in case SvxBrushItem / RES_BACKGROUND was to be get/set, it mapped that
to svx's fill style.
This has two problems: 1) it does not work (see the failing unit test)
and also page style editing UI sets SvxBrushItem, so even if the UI is
used to (actually successfully) set the page background, it won't be
saved to ODF.
So, do this background <-> fill style mapping only for frames for now.
Change-Id: I734880a40c891ae9e341cbddf8f88b0462361aac
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: Ie656f9d653fc716f72ac175925272696d509038f
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>
It appears that this was just a workaround that incidentally worked.
Making the negative value even larger (in abs value) doesn't seem to make
a difference for MSO, but LO fails again. A proper fix (better workaround?)
will follow.
This reverts commit 76aa23c59b4c81ea7b9d974a1a0a9e39c6bf8741.
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
The BRC (BoRder Control) structure used in .doc files to specify border
properties has undergone several revisions over time. LibreOffice
supports the WW6 and WW8 (Word '97) BRC versions, which allow the border
colour to be selected from a palette of only 16 colours.
This changeset adds support for the WW9 (Word 2000) BRC version, along
with some new SPRMs (Single PRoperty Modifiers) which use it, so that
border colours are preserved accurately in .doc import/export.
This change covers:
- page borders
- paragraph borders
- borders around a sequence of characters
- table / table cell borders (import only)
Further work is required to extend coverage to borders of pictures and
export of borders in tables.
The LO code was using the same class WW8_BRC to store the bits for either
the WW6 or WW8 BRC. This becomes a bit unmanagable when adding a third
BRC version, so I have split this into a separate class for each version.
Fixes fdo#68475, fdo#50185
Change-Id: I7ebc15236497cbab9312d8659fe7ed0bee2c59ed
Reviewed-on: https://gerrit.libreoffice.org/8646
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
These controls don't have a special property, like for example
unformatted text controls have. So we use the id property as a
marker; we will grab-bag it together with other sdt properties and
use the existing mechanism to write the sdt block on export.
A grab bag that only contains an id property is for sure a rich text
control so we add it to the character props and not to the paragraph
props, like in the case of the unformatted text control.
Word doesn't allow us to write an empty <w:id/> tag, so we fill
it with a random number.
Finally, modified an existing unit test to add a rich text control and
check it is exported correctly.
Change-Id: If403a4a2393d4ee069a628645e364d21f104a859
