Age | Commit message (Collapse) | Author |
|
Although 2013 commit 60ec497e0e91354a616978be531d15d3efa3f559
added support for the other tcMar items, it omitted _start and
_end (perhaps because they caused unit test failures).
The document in bug 78508 proves that these are needed.
Testing whether the cell spacing matches the default table
spacing should occur before adjusting for MSO compatibility.
This fixes the three unit tests that mysteriously failed
when adding _start/_end support.
Unfortunately, these two fixes could not be committed
separately - the unit test fails unless both parts
are included. I couldn't figure out why.
Change-Id: I9507da48b629b9618c5ee790bf0088ce82fc5692
Reviewed-on: https://gerrit.libreoffice.org/43432
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Handled Header/Footer that are specifically for Left/Right pages the old
way again. Fix done previously was too much.
Change-Id: I0f9e8d23022300a06bd3fb45054cca1b03cf096f
Reviewed-on: https://gerrit.libreoffice.org/43749
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: I143e8df0e16ad921777b9caabde8e1c3f8bd61df
Reviewed-on: https://gerrit.libreoffice.org/43788
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
Upper, lower and contextual spacing are all stored in SvxULSpaceItem, so
if after spacing is set as direct formatting, contextual spacing has to
be set directly as well (having it in the paragraph style has no
effect).
Change-Id: Ie331c7561de7f2f16776a1613717e38fa083a541
Reviewed-on: https://gerrit.libreoffice.org/43735
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: Ic42219a7d733897ba47b26ffa0659c524798878e
|
|
no need to explicitly specify it anymore
Change-Id: I6ad9259cce77201fdd75152533f5151aae83e9ec
Reviewed-on: https://gerrit.libreoffice.org/43567
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7855c76e820efce96778b1c19ec71dffcc4b4abb
Reviewed-on: https://gerrit.libreoffice.org/43621
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I94535a51a87be097ff7356edff935877b42c3272
Reviewed-on: https://gerrit.libreoffice.org/43598
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
During parsing of the docx the paragraph without w:bidi
should take this value from style or from default paragraph properties,
Change-Id: Ie33f0d1cd3551c4053a47e6faf7dcac71765db65
tdf#87533 explicitly set writing mode value based on default properties
Change-Id: I3fcf514a901f0630d749ba0ddb6361d6db3ce1b5
Reviewed-on: https://gerrit.libreoffice.org/42895
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I90d220550d24fb964cf4e528a1f506033f05de95
Reviewed-on: https://gerrit.libreoffice.org/42896
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: Ie29a05fec90c0d81b4a0399505b0a6761dfdef69
Reviewed-on: https://gerrit.libreoffice.org/43463
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I336d5a498f4f4523e03b1316b7adaca21df4de82
Reviewed-on: https://gerrit.libreoffice.org/43385
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
This patch is also required for tdf#78508.
ECMA-376-1:2016 indicates that MeasurementOrPercent
is a union of ST_DecimalNumberOrPercent and
ST_UniversalMeasure. For the elements that use
MeasurementOrPercent, that is represented as
1/50 of a percent or in Twips. This patch adds
support for the ST_UniversalMeasure component of
the union.
Change-Id: I1bac30707f118a3d1f0eab3c27f8dcec96470592
Reviewed-on: https://gerrit.libreoffice.org/43384
Tested-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
The marker trick is not needed for these, but the paragraph margins are
lost when using it, so avoid it.
Change-Id: I3fc9644cb85138b5473cb1478196ae8538041fb1
Reviewed-on: https://gerrit.libreoffice.org/43446
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Likely a copy/paste error, imported from OOo.
Change-Id: I29713309164170e86f8e793e2f15a601ce2b5da7
Reviewed-on: https://gerrit.libreoffice.org/43431
Reviewed-by: Justin Luth <justin_luth@sil.org>
Tested-by: Justin Luth <justin_luth@sil.org>
|
|
Change-Id: Iab17008c8cc122176fb51b8766540d59cd681b35
Reviewed-on: https://gerrit.libreoffice.org/43316
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Commit 56a695fddb915bcba13b088b5b2b4e0841d4acbc (tdf#112211 RTF import:
fix unwanted direct formatting for left indents, 2017-09-26) fixed left
indents, and given that it was a regression fix, left the other indent
types untouched.
As it has been pointed out in the bug comment, the original bugdoc
actually needs the other indent types removed as well, so let's do that.
Change-Id: Ia4ea7e2214b7df27536f46b046f90bd703c107be
Reviewed-on: https://gerrit.libreoffice.org/43303
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: Id08998ae775c5f383edc4bf0410d16f88c70dfd6
Reviewed-on: https://gerrit.libreoffice.org/43275
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I60644bd62e2a2ac97a97f0a492b146dc69456cd6
Reviewed-on: https://gerrit.libreoffice.org/43291
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: Ib28833555661b119de8e967b05e3c8691fca826a
Reviewed-on: https://gerrit.libreoffice.org/43227
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
|
|
Change-Id: I39caad06bcd645d582c180195a839113759b57a1
Reviewed-on: https://gerrit.libreoffice.org/43159
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Added:
+ import/export of all doc protection properties
+ unit test
Change-Id: I7b65cf4f5c7add2a96fef407c243081fcc2b6d8d
Reviewed-on: https://gerrit.libreoffice.org/43156
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
which started happending at...
commit 56a695fddb915bcba13b088b5b2b4e0841d4acbc
Date: Tue Sep 26 09:13:05 2017 +0200
tdf#112211 RTF import: fix unwanted direct formatting for left indents
Change-Id: Id3e8c4452238b48495b1014eff14cdaddcb047ab
Reviewed-on: https://gerrit.libreoffice.org/43172
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
[cpp.include] tells that includes in <> are searched in implementation-defined
places; includes in "" are searched in other implementation-defined places,
and is unsuccessful, then as if they were in <>.
MS VisualStudio IDE uses paths configured for the project for includes
in <>, and starts with current file paths for includes in "". So, using
<> for includes in current source file's directory missing from configured
project paths makes IDE show unsuccessful includes and unknown identifiers.
This fixes includes in writerfilter source directory.
Change-Id: I0bc1147aa68c305afd0c119418f07b655783a466
Reviewed-on: https://gerrit.libreoffice.org/43138
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ia23dafd07133779144965682df3b7125a3214235
Reviewed-on: https://gerrit.libreoffice.org/43046
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I590de2fd15c630d5ea5e706ce9421ee8bfe19db7
Reviewed-on: https://gerrit.libreoffice.org/43116
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Commit e6ec0794858df1444f43659b568119bf126a90e6 (tdf#104937 RTF import:
\trwWidthA is an absolute value, 2017-08-29) changed the handling of the
fake empty cell at the end of table rows so that the parameter of the
control word is an absolute, not a relative value. Turns out this
wasn't correct, the DOCX equivalent of that bugdoc shows that the
parameter is a relative value after all. The RTF spec also talks about a
"width", which is assumed to be a relative value.
So fix that bug in a different way again (by making sure that this
additional fake cell contributes to the total width of the table, so
column separators are counted correctly), this time without less
side-effects.
Change-Id: Ic64fd3a6abae8e0398e8e77123f0473d73f0c4b0
Reviewed-on: https://gerrit.libreoffice.org/43063
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I7b68b70fa4c7234e8882f7627026959a596968fd
Reviewed-on: https://gerrit.libreoffice.org/43025
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
it's obviously not a real problem, because higher up code calls this
even if it doesn't intend to use the result, and in the places where it
does intend to use the result, it warns again, so this warning is
redundant.
And it's the 3rd largest number of warnings in our logs.
Change-Id: I1a6c40bc99a3252594f87e121a81c661686c5348
|
|
This reverts commit 25cd067a82742210793e39708cc1de9ff84692a7, as it
broke CppunitTest_sw_ooxmlexport4. The comment above the change suggests
that perhaps the usage of indexes was intentional to avoid the usage of
invalidated iterators.
|
|
Change-Id: I424fd1bf8eef7112a8cff54ab46a07bb41596ca5
Reviewed-on: https://gerrit.libreoffice.org/42901
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I5c7d107a05deb06749b4d04246ba183adfafb14d
Reviewed-on: https://gerrit.libreoffice.org/42829
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Prior to commit 9920a0bf9d783978cd6f7b97f7528d8aa2571143
the style could only contain the default of NONE. So when
a position was specified, it was always paired with
HoriOrient == NONE. So it never caused problems until
that commit when the Frame's style orientation started
overriding the unset paragraph default.
When a position is specified, that needs to be paired with an
orientation of NONE in order to take effect.
Change-Id: Iab0057810270ba708a8855c2ec6db291cef17cfb
Reviewed-on: https://gerrit.libreoffice.org/42499
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Commit f528f9499bd91b700c549575e88fa102cfffede9 (tdf#106953 RTF import:
fix missing paragraph left margin, 2017-05-16) fixed a problem around
inheriting indents from numbering styles vs paragraph styles, but it
turns out that document was rather special and in general the old
behavior was correct. So fix that bug in a different way again, this
time without less side-effects.
The trick is that in case the level numbers group in a list definition
ends with \u59 (instead of an ASCII ';'), then that group is considered
to be invalid by Word. RTF import already was aware of this, but it
wasn't known that when this invalid state is reached, that also means
that the indents of the list level definitions should be ignored. So in
general not putting direct formatting on a paragraph is a good thing:
that way in case the paragraph style and the number style both has
indent infos, then the numbering style wins, and that is what we want --
but in case \u59 appears in the list definition, then the indentation
from the numbering style should be ignored.
So fix up the tokenizer to import the indentation from list levels in
general, ignore it for invalid list levels, and then we can remove the
direct formatting from the paragraphs, which fixes this bug and keeps
the old one fixed as well.
This required fixing up two poor testcases, which tested paragraph
properties, but in fact are interested in the real source of
indentation, which is now the numbering style. Visually both bugdocs are
unchanged.
Change-Id: I6390aa870659a8ad02ba5512d84dea34dba29e9f
|
|
...instead of RTL_TEXTENCODING_DONTKNOW. (A file actually using that codepage
is sw/qa/core/data/rtf/pass/CVE-2014-6357.rtf, processed by
CppunitTest/sw_filters_test, where it caused OStringToOUString to be called with
RTL_TEXTENCODING_DONTKNOW from
writerfilter::rtftok::RTFDocumentImpl::resolveChars.)
Change-Id: I41081c5df5c3aa80b4f1c7d52b158e73ef68cf38
|
|
Hopefully with this it's easier to see which is the usual and which one
is the exceptional case.
Change-Id: Iac1b49b2a4f2b909db46155d1ff10d2ba99fd655
|
|
<https://msdn.microsoft.com/en-us/library/windows/desktop/
dd374130(v=vs.85).aspx> "WideCharToMultiByte function" suggests that there now
is CP_SYMBOL, "Windows 2000: Symbol code page (42)." And a little test program
on Windows indicates that our RTL_TEXTENCODING_SYMBOL is working the same way as
CP_SYMBOL, where MultiByteToWideChar maps 00..1F to U+0000..1F and 20..FF to
U+F020..F0FF.
At least CppunitTest_writerfilter_rtftok, when testing
writerfilter/qa/cppunittests/rtftok/data/pass/EDB-18940-1.rtf, goes into case
RTF_FCHARSET in RTFDocumentImpl::dispatchValue
(writerfilter/source/rtftok/rtfdispatchvalue.cxx) with nParam matching
aRTFEncodings[2] (i.e., a mapping from charset 2 to codepage 42, see
writerfilter/source/rtftok/rtfcharsets.cxx), then passes 42 into
rtl_getTextEncodingFromWindowsCodePage and obtains an unhelpful
RTL_TEXTENCODING_DONTKNOW.
testFdo72031 (sw/qa/extras/rtfexport/rtfexport2.cxx, CppunitTest_sw_rtfexport2)
needed to be adapted, as the circled plus from the Symbol font is now internally
represented as U+F0C5, not (somewhat bogusly) as U+00C5 (aka LATIN CAPTIAL
LETTER A WITH RING ABOVE). But, when displayed with the Symobl font, the glyph
that is actually shown remains the circled plus.
Turns out changing rtl_getTextEncodingFromWindowsCodePage would start to make
CppunitTest_sw_rtfimport fail:
Sep 20 15:49:24 <sberg> vmiklos, with
<https://gerrit.libreoffice.org/#/c/42477/>, testN823675
(sw/qa/extras/rtfimport/rtfimport.cxx) fails, the aFont.Name is not "Symbol";
sw/qa/extras/rtfimport/data/n823675.rtf contains a \fonttbl that specifies
\f3 to have \fcharset2 (i.e., symbol font) and fontname "Symbol". However,
RTFDocumentImpl::checkUnicode
(writerfilter/source/rtftok/rtfdocumentimpl.cxx)
converts m_aHexBuffer (containing "Symbol;") with nCurrentEncoding apparently
being the encoding specified by \fcharset2 (i.e., now RTL_TEXTENCODING_SYMBOL
instead of old RTL_TEXTENCODING_DONTKNOW), so the resulting OUString is
garbage
(instead of the byte-for-byte conversion to Unicode "Symbol;" that
RTL_TEXTENCODING_DONTKNOW would do there); do you know whether such \fonttbl
fontnames should actually be interpreted in the given \fcharset?
Sep 20 15:49:24 <IZBot> gerrit: »Map Windows code page 42 to
RTL_TEXTENCODING_SYMBOL« by Stephan Bergmann for master [NEW]
Sep 20 15:51:15 <vmiklos> sberg: let me check if the spec covers that
Sep 20 15:54:29 <mst_> sberg: i think the name is typically encoded in the
font's encoding but probably they have to make a (likely undocumented)
exception for symbol encoding
Sep 20 15:57:46 <vmiklos> sberg: the spec only says that \fcharset is about
the encoding of the content using that font, i don't see it described what
would be the encoding of the font name itself
Sep 20 15:58:51 <vmiklos> sberg: i'm not sure about if that encoding should or
should not affect the encoding of the font name in general, but indeed at
least for 2 (symbol encoding) you're right, Word doesn't encoding the font
name with that encoding, either.
Sep 20 15:59:30 <sberg> vmiklos, mst_, at the top of page 14 of
Word2007RTFSpec9.docx I see "Note that runs of text marked with a particular
font index (see \fN in the Font Table section) use the codepage for that font
as given by \cpgN or implied by \fcharsetN, unless they use Unicode RTF
described in the following section." Would that match what mst_ says?
Sep 20 15:59:33 <vmiklos> so if it helps you case to handle at as e.g. ascii,
just for that encoding, i think there would be no problem with that.
Sep 20 16:00:07 <vmiklos> sberg: that still talks about the content using the
font, not the strings (font names) in the font table itself, i think.
Sep 20 16:01:17 <sberg> vmiklos, what's the control word to select such a
font, also \fN? I don't see any such in n823675.rtf
Sep 20 16:02:16 <mikekaganski> loircbot: e.g. \af3
Sep 20 16:02:31 <mikekaganski> sberg: ^
Sep 20 16:02:47 <mst_> 04d5a280beeeb6e056df68395dc9c3b3a674361b
Sep 20 16:02:50 <IZBot> core - related: fdo#77979: writerfilter RTF import:
read encoded font name -
http://cgit.freedesktop.org/libreoffice/core/commit/?id=04d5a280beeeb6e056df68395dc9c3b3a674361b
Sep 20 16:02:52 <mst_> sberg: ^
Sep 20 16:04:05 <sberg> mst_, thanks; so there's likely an (implicit?)
exception for \fcharset2, as you say
Sep 20 16:04:33 <mst_> that's most plausible, our own font code is full of
exceptions for "symbol fonts" too
Sep 20 16:05:19 <sberg> mikekaganski, ENOCONTEXT
Sep 20 16:05:36 <mikekaganski> sberg: [17:01:16] sberg: vmiklos, what's the
control word to select such a font, also \fN? I don't see any such in
n823675.rtf
Sep 20 16:06:32 <sberg> mikekaganski, so you say selection is done with \af3
instead of \f3?
Sep 20 16:06:40 <mikekaganski> sberg: yes, in that case
Sep 20 16:07:34 <mst_> i think there are several different keywords that apply
fonts, but can't remember the whole list
Sep 20 16:08:10 <mst_> \fN shoudl be one of them though
Sep 20 16:22:18 <sberg> vmiklos, so who generated that
sw/qa/extras/rtfimport/data/n823675.rtf, was it manually created and lacks a
\cpgN before "Symbol"?
Sep 20 16:29:17 <sberg> vmiklos, (after further reading of the RTF spec):
disregard the "and lacks a \cpgN before 'Symbol'" part of my above question
Sep 20 16:30:27 <mst_> sberg: i suggest not reading too much about encoding in
RTF, it gets pretty lovecraftian pretty fast...
Sep 20 16:32:58 <vmiklos> sberg: given how short that bugdoc is, i'm pretty
sure i cut it down manually to something readable from a multi-MB real bugdoc
Sep 20 16:33:07 <sberg> mst_, do you have a recommendation how I could get
that "don't use symbol font encoding to read a symbol font's name" into
writerfilter/source/rtftok/rtfdocumentimpl.cxx?
RTFDocumentImpl::checkUnicode lacks the context to tell whether it is using
m_aStates.top().nCurrentEncoding to convert a fontname, and the caller of
checkUnicode (at the end of RTFDocumentImpl::resolveChars in this case)
appears to lack the context, too
Sep 20 16:33:12 <mst_> various Old Ones from The Time Before Unicode and their
Backward Compatibility Tentacles etc.
Sep 20 16:34:59 <sberg> vmiklos, anyway, that "so there's likely an
(implicit?) exception for \fcharset2" hypothesis sounds sane, so we should
probably implement it (if only you or mst_ can give me a good hint how...)
Sep 20 16:35:13 <vmiklos> sberg: looking for a code pointer
Sep 20 16:36:05 <mst_> sberg: m_aStates.top().eDestination ==
Destination::FONTENTRY should be the relevant check?
Sep 20 16:36:17 <vmiklos> sberg: RTFDocumentImpl::text() is where the text is
taken, Destination::FONTENTRY is the state on the parser stack which is a
font entry in the font table. so to detect "your case" during decoding a byte
array into a string, m_aStates.top().eDestination == Destination::FONTENTRY
is what you want
Sep 20 16:36:35 <vmiklos> ah good, two independent matching hints are
promising ;)
Sep 20 16:37:35 <sberg> mst_, vmiklos, ah; but what also looks dodgy is that
checkUnicode operates there on "Symbol;" including the closing ";" of the
full <fontinfo>, not just the <fontname> part of the <fontinfo>
Sep 20 16:39:24 <vmiklos> sberg: i think we already assume that the only
"token" in the font entry destination that is not bound to a control world
(\foo) is the font name
Sep 20 16:40:52 <vmiklos> sberg:
writerfilter/source/rtftok/rtfdocumentimpl.cxx:1237 is where we simply strip
away the trailing semicolon, there is no further separation between the font
name and other character content inside the destination (apart from the
control words and their arguments)
Sep 20 16:42:18 <sberg> vmiklos, OK, thanks; I'll just pretend I haven't seen
those dodgy details :)
...so I'm switching to (somewhat arbitrarily) RTL_TEXTENCODING_MS_1252 there now
Change-Id: Iebd1bcecb7fa71c489798154d3356062b052775e
Reviewed-on: https://gerrit.libreoffice.org/42477
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I69d4157aaf6570cecd51ea59df20556914942e06
Reviewed-on: https://gerrit.libreoffice.org/42565
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ie3eede03b90db272d70e7cb383c7a69d9db0f2ae
|
|
ever since
commit 0929dfa83ca4dbc675c74854566ce4e25def0dbd
Date: Sat Jan 11 11:54:14 2014 +0100
writerfilter: drop never generated rtf
{XAlign,FHDR,YAlign,XRelTo,YRelTo}
Change-Id: Icabe9ff848e3cc9918741e9c68d8f2312145fb74
|
|
ever since
commit 4a924576e415f16e0571542bb0d683529f9046ff
Date: Wed Jan 15 20:24:41 2014 +0100
writerfilter: drop unused BlipDib and FSP in doctok
Change-Id: I9bf644bdc4b37cb6c4a9a9ab7757c4a83a520cd7
|
|
ever since introduction in
commit 328d154015f8cb733ed62d793bbbc31eb4cc971b
Date: Fri Jun 10 18:56:08 2011 +0200
resolvePict: import the stream as a graphic object
Change-Id: Ife03094d721621cc592be9cd94899a4e40550330
|
|
Usually a DOCX numbering definition has multiple levels, each level
containing a <w:ind ... w:hanging="..."/> element. When this is missing,
we should default to the Word default, not to the Writer one.
This makes the DOCX version of tdf#106953 imported correctly, in
preparation of dropping the original fix that helped RTF only.
[ The DOC version of the bugdoc is still not imported correctly. ]
Change-Id: Ib7fc1de55316a73188c023665a585ac7056341f7
Reviewed-on: https://gerrit.libreoffice.org/42447
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
In other words, let's open documents in the non-web view even when saved with
<w:view w:val="web"/>.
The behavior I see in Word 2013 (and it's documented that his happens in 2016
too) is that the setting is not a document setting any more, but user's
setting. Ie. regardless of what is written in the file, the .docx document
opens in the Print Layout if the Word was in the Print Layout until now, and
in the Web Layout if it was that mode.
We handle the non-web layout much better than the web layout, so let's just
default to the normal layout on load.
Change-Id: Ieba7ddc280b9b79501a6b89ff21b03a86356583c
Reviewed-on: https://gerrit.libreoffice.org/42414
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
|
|
Translates leftovers found using a custom regex in directories beginning with "w" and "x".
Additionally:
- A few corrections of previous translations
Change-Id: Ic30cf6792748a6bea8782a9a3711fa468b80bdaf
Reviewed-on: https://gerrit.libreoffice.org/42378
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
...when t1 is ElaboratedType sugar (which isn't only used when the type is
written with an elaborated type keyword, but also when it is written with a
qualified name).
(I originally wrote testArithmeticTypedefs to track down a different issue,
which turned out to be a non-issue, with this fix as fall-out. So that test
doesn't quite match the theme of this commit, but is a worthwhile addition
nonetheless.)
Change-Id: Ic447da4399853d7d045e3e2e7ade8ddf52d89749
|
|
Change-Id: Id1bbd3f380c17beeaab11f7140d4df1304c3d0d8
Reviewed-on: https://gerrit.libreoffice.org/41750
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and simplify some of the calculations that needed to be changed.
Which resulted in one unit test needing to change by one pixel,
let's hope not an indication of a real problem.
Change-Id: Ie56434f35f4e58d21ee6f671392e93dc7542fca3
Reviewed-on: https://gerrit.libreoffice.org/42240
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This also makes ww8 floating-table conversion decision heuristics
somewhat closer to OOXML code.
Change-Id: I29ca2ebabd1758ad98e02aaf560cf2f44daec3a8
Reviewed-on: https://gerrit.libreoffice.org/42196
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
This reverts commit 39c08074a286855dd014ce1c30b8f7ef95b10242.
Fixed by: I69517efb7d82acd719d6a27a09ba61554dbf1ec9
Change-Id: Icd45b3f55292670ff7338a367eba212453a0687e
Reviewed-on: https://gerrit.libreoffice.org/42155
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|