Age | Commit message (Collapse) | Author |
|
lcov pointed out this method wasn't ever invoked in any of the tests.
Change-Id: I6cccf4fc1d870938a2f218bedc0b8d195a299cd1
|
|
Currently LO writes table cell border information to .doc files as part
of the "sprmTDefTable" property, but this only supports the WW8 (Word '97)
BRC (BoRder Control) structure which can only select from 16 colours.
There is no newer version of this property.
This commit adds output of an alternate property "sprmTSetBrc" which
specifies border details for a sequence of cells. There is a WW9
(Word 2000) version of this property supporting full colours.
For LO I have used the constant name NS_sprm::LN_TSetBorder following
the existing naming convention here, which is to use *Border for the WW9
version because *Brc is taken for the WW8 version.
Conflicts:
include/filter/msfilter/sprmids.hxx
Change-Id: Ie091d91c6d187e1c2542f59f58cec9a373a23e11
|
|
Change-Id: I58d9ccd0e2086f96ce6a51578d51db3fcb577400
|
|
Change-Id: I4c68ea7061af04616eda27365b16cfa57200ffbc
|
|
Change-Id: I5fc9d24390d0a90f89c3e71e87bf37ddd9c2fe67
|
|
Change-Id: Ie4b540b2d49841182769946c4ce8d39cb2d7a3fe
|
|
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
|
|
Change-Id: I9ac19624a611a6468979aa8771662845356ca365
|
|
Change-Id: I2cafd91841801ef22272ba83de2ce6294ca61918
|
|
Change-Id: I22e7872e45cca981a0b2c24ca8b0393ba1244612
|
|
Change-Id: I0f1cf705d0eea78b5bf44e0d6b882f7c8636a6ac
|
|
Change-Id: Idfdeca8e19438081acabd51aa72d7f6322c4b31b
|
|
Change-Id: I7cb047271af6ffa789c6e18a8dbd2a7dddcdc15c
|
|
Change-Id: Ib62f992814ec83f3bb25a0197b50b0b85979d0bb
|
|
The 2 for PrepareClose came in with 38db42605a5b72efd55a43eff81fbc517fe0424b
"#89423#: added SID_CLOSEDOC, SID_BACKTOWEBTOP, SID_LOGOUT in PluginMenu" and
was checked with if( SfxApplication::IsPlugin() == sal_False || bUI == 2 ) in
sfx2/source/doc/objxtor.cxx and then that was removed with
367568c891771d20bb8f8b3b579857f51c0e9016 "#132394#: remove superfluous code"
Change-Id: Ib273c88b4365ea6b261c7e52bbe1876aa796dc17
|
|
looks like I missed a couple of methods in my earlier conversion
Change-Id: I07871a451bb5954feab57de0af4f7d0678f9a7b3
|
|
Change-Id: Id557d9cc37e38d017efbb5b4d77070affe00f4b9
|
|
Change-Id: Icf882b97fec554bb25063f092d628c140dae60be
|
|
Change-Id: Icbe926c133fd79c0a420578332ae2b6abdbdea9b
|
|
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
|
|
This time hopefully for real
Change-Id: I5bf06a9353ea94aef04d862ab25dfc38129b2b12
|
|
Change-Id: I23ad8bcbef9a0ef17aaa5d401d111c40a6560ee2
|
|
Change-Id: I3c6ff1750d3e6aa6b3b19c957847289067fc5a54
|
|
Code looks cleaner like this.
Change-Id: I43bd8d2ac40960347d60e687dcae4c17357991b0
|
|
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
|
|
Change-Id: I372e373844169f216fb856107cc10b063d99e31d
|
|
Change-Id: Icafdd4780eebd6356bf2070ff99dbba9d6956c16
|
|
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
|
|
on deleting a full table
Change-Id: I03af8bcbae41e78229163a945a74387f53787ca5
|
|
Change-Id: I23c80a462ef473defe5536f9090167ae734553b7
|
|
Change-Id: If59c5c4901aeec404099c810a021eea8b8b3d3ab
|
|
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
|
|
i.e. convert "::sal_Bool" to "sal_Bool"
Change-Id: Ie5943aee4fee617bf2670655558927ed25b7e067
|
|
the widget in glade for changing ellipsize gets focus and when you mouse wheel
up and down often it gets accidentally changed, sigh.
Change-Id: I6dc0dc6d9985ea0ff9a34817291e642a9706bf0f
|
|
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
|
|
Change-Id: Icda048beb9b4b580cdf2843ee34698decc035d04
|
|
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
|
|
Change-Id: I0fb2827c41024216f574266e61a11b1cbb7bce28
|
|
Change-Id: I6938314a08d061d2b07d9129742d74a989bd1385
|
|
Change-Id: I24deda680469ce99ba358a68e83551bdb584751a
|
|
Change-Id: Ic4bcc2fa02426e1995d08a6992cc5b35777c1c9a
|
|
With this, it's possible to see properties of e.g. fly frames in a
document.
Change-Id: Iba68156ba7f0149dfea3e0a6367b71b8642a2a80
|
|
Change-Id: I0b11aaa3efd5176a3a7c124bd15d50962ee7e90e
|
|
Change-Id: I8f1687ba7aacfff47695fd43062c92d2eb034a29
|
|
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>
|
|
Change-Id: I12bdb00e89978c977d1d9cb721462bf23849a876
|
|
Change-Id: I7d789c2467c03a20d033b146ef2f89cbf6e9104a
|
|
Change-Id: Ie7542d39555be3c649a0712a147281cc1066ca2f
|