ODF 1.2 specifies '!=' as not equal operator in <number:number-style>
<style:map> style:condition attribute. So far '<>' is written, accept
the correct operator.
Change-Id: I6087992ee35fff5c7aa52b7cec2b83b0a78dbac1
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 bbe3627eec (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
We need to extend PUT method with lock token in 'If' header, so that it
does not fail on a resource locked by us.
Change-Id: I82a9e3303a34607dba8bb874d1eb0fac23b9f11d
The idea is that when an element is unhandled, it's either unhandled
explicitly by an empty "case..break" block (so grep can quickly find it)
or we raise a warning. Add a few placeholders for cases that we won't
probably handle better in the near future to silence warnings.
Change-Id: I41dec7802c4671550130393b4f98a8f0d8dfc059
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
Since commit 9dc57be59d under
Tools->Options->LanguageSettings->WritingAids "User-defined
dictionaries" the language strings are displayed as
" '[' Language (Country) ']'"
that before was and instead should be
"[Language (Country)]"
Change-Id: Id7e7ef6ab86112c46707f1451a072dfc196aec44
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
1c22545edf (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
