Age | Commit message (Collapse) | Author |
|
Change-Id: Ic1b6681a3f48ef0fe3f52eda9db8b7bc003ded55
(cherry picked from commit 98151bf95bda8d647310bdba6936dc6b388b05de)
Reviewed-on: https://gerrit.libreoffice.org/36098
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
(cherry picked from commit 14028af4d978f126779e641a9605c6d4d864b3b6)
|
|
Moved Label above the content area
Change-Id: I0a23af5540bedc849c83fd342ac43538827e6b4a
Reviewed-on: https://gerrit.libreoffice.org/36071
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
(cherry picked from commit 3873669fef3cac05a9b530de08f15e0d2a3fdc57)
Reviewed-on: https://gerrit.libreoffice.org/36105
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
(cherry picked from commit c15eba1b1de9c41acd76f0b2a16cfbe38bf4fccb)
|
|
(cherry picked from commit f1a53e7a0b388e0a5303fe68dfbb4c60f4c7a0ff)
Change-Id: I00cf16e9ce429f9186cc900a07f4d386e33b8f7b
Reviewed-on: https://gerrit.libreoffice.org/36083
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
(cherry picked from commit 8e0220ce0d9e20577694b56011cfe34d1bc35fc5)
|
|
Change-Id: I9b4074e1024753549f468f427afbfdf9cd01b674
(cherry picked from commit d30fb62f4f1022ae6294e246974d0018596cf8ec)
ofz: guard harder against bogus sprm len
Change-Id: Ic82526e1454b24f094d3deee89647e88760bc44b
(cherry picked from commit 924624b40a97d6925f66374259c2c21707805fcd)
Reviewed-on: https://gerrit.libreoffice.org/36078
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
(cherry picked from commit feecc82753c48b1c82df2315896b9996e33af2e2)
|
|
Change-Id: Ie034e3b37e01c29cf19fe8ad78b1121f6eadecb2
Reviewed-on: https://gerrit.libreoffice.org/36053
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit 29cf858a971273039fff50808082f231dbd43c92)
Reviewed-on: https://gerrit.libreoffice.org/36075
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
(cherry picked from commit 5d5731a372e540fbb9344533b6dd7e06fc123687)
|
|
Change-Id: I07779bec876b90e36f20a81d6dbf06ae727edf85
(cherry picked from commit fb05611064e12c8eda09bc32c42544cde8c2ab49)
Reviewed-on: https://gerrit.libreoffice.org/36018
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
(cherry picked from commit daa13c049f1d527e51a776f75748ddfba4e9666b)
|
|
Change-Id: I6288aae2d439cde6a2b95c005a2090f73e21bb7a
(cherry picked from commit 3feabd87ad8066b45b55d61cd72684e47fd79082)
Reviewed-on: https://gerrit.libreoffice.org/36051
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
(cherry picked from commit 09f5f4a39e4a9304d81565c33c009e8e0552778d)
|
|
... upon successful return from INetContentType::parse
Change-Id: I8a0c50c1c655477138578e59031b64fb6b2b7218
Reviewed-on: https://gerrit.libreoffice.org/36129
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 97f048e633f07655eda000ae4f4da818c935091e)
Reviewed-on: https://gerrit.libreoffice.org/36146
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 6e336c43a239f515cc882a3da1bad63e3507b230)
Reviewed-on: https://gerrit.libreoffice.org/36236
|
|
Change-Id: I7ae94c7717fbea03d96c539e05eeb565bafefd9f
Reviewed-on: https://gerrit.libreoffice.org/36188
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 0c547776340c3983a867890b34f4a931215f8f52)
Reviewed-on: https://gerrit.libreoffice.org/36203
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
According to Extensible Markup Language (XML) 1.0 (see
https://www.w3.org/TR/2008/REC-xml-20081126/#sec-prolog-dtd),
all parts of XML prolog (including XML declaration) are optional,
so XML stream without <?xml ... ?> is well-formed (though not
valid).
XMLFilterDetect uses only XML declaration to detect if the file is
to be processed further. However, this creates problems with said
documents.
This commit checks if the document has MediaType set to one of
known XML media types, in case when the check for XML declaration
failed.
Change-Id: I31627c0e3a39bee241f609650280ebac3f1cede8
Reviewed-on: https://gerrit.libreoffice.org/36101
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 156f778593ca9c57845076a88c6b544a63e12e7a)
Reviewed-on: https://gerrit.libreoffice.org/36133
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
When PROPFIND fails on a WebDAV resource, its IsDocument property
stays undefined, and so stream creation fails. Proposed solution
is to default to IsDocument=true for all WebDAV documents where
we cannot get the property from server.
Such resources also fail to return their locking options, so
defaulting to server properties. When later locking is attempted
on it, the attempt fails with user notification (a dialog saying
that getting information from server failed). Proposed solution
is to check Content-Disposition header in such resources, and in
case it's attachment, disable lock on this resource. The rationale
for this is that "In a regular HTTP response, the Content-Disposition
response header is a header indicating if the content is expected
to be displayed ... as an attachment, that is downloaded and saved
locally" (see MDN:
https://developer.mozilla.org/en/docs/Web/HTTP/Headers/Content-Disposition
Also, Content::getProperties wasn't ready for PROPFIND returning
empty result.
Change-Id: I91dbffa8bdf0fe900c11d2f8c9c9394d2104bb49
Reviewed-on: https://gerrit.libreoffice.org/36090
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit fbc04c97231d629c1b5e9e57203dbe8d8eb06714)
Reviewed-on: https://gerrit.libreoffice.org/36132
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
There are online services and management systems (like SharePoint)
that allow to export datasets in ADO rowset XML format ([MS-PRSTFR],
https://msdn.microsoft.com/en-us/library/cc313112). Usually they are
intended to be open with MS Excel as a spreadsheet (with autofilter).
This allows to open this data in Calc.
Change-Id: I495cd790138bdd6bd24630c0f422a0c8b4e3d0fb
Reviewed-on: https://gerrit.libreoffice.org/35159
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit d6323a2180cf51f9bd6a62d50503c2e0ef0964f1)
Reviewed-on: https://gerrit.libreoffice.org/36131
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ieda51d7a4b91d9c107aa5550e27ba11c613ae5a9
|
|
When copying their page steam into ours, we need to make sure their
syntax is <= 1.4; so when checking if the image has PDF data, ignore the
case when it has, but it's >= 1.5 (at least in the default case when not
using reference XObjects).
Change-Id: I6bd77803b92fe16bdd327e5e7c3d2b42adeacca4
Reviewed-on: https://gerrit.libreoffice.org/36161
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
(cherry picked from commit 4443d7be61a9ae45630183d856a566cecd06ad95)
|
|
There were a number of problems here:
- the /Resources key of a page object may be an indirect object
- the /Font key of a resource object may be an indirect object
- the /Length key of an object may be an indirect object
So in all these cases handle not only a direct dictionary / number but
also when we have a reference-to-dictionary/number.
Change-Id: Ie74371f0ba43a133a1299843ef20cbfc75fe26d7
(cherry picked from commit 242a9b634213acf03cabc373928555dc81afc672)
|
|
Change-Id: I6181b27b6a969d94789c42ea0914b17328c5c8d5
Reviewed-on: https://gerrit.libreoffice.org/36109
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
|
|
The row parameter type was a unsigned short.
Change-Id: I2da1a96d60988e8f1efeb49f55032fb84a8b562b
|
|
Due to previously intruduced optimizations, it is safe and fast enough
to navigate through a 500k rows document.
Change-Id: I8055672b58ea3c1e262f6e49d029eb0cf67086b5
|
|
Now the computation of the row/column headers data exploits the cached
row/col positions in HeightHelper/WidthHelper.
That makes updating row/column headers at the bottom of the document
as fast as at the top even for very big spreadsheets.
Change-Id: Ida0ed8d8885b71fe3206efbdaa62a0bb95153ed7
|
|
Now the computation of the cell cursor position exploits the cached
row/col positions in HeightHelper/WidthHelper.
That makes navigating through arrow keys independent from the current
cell cursor position: the cell cursor position is updated at the
bottom of the document as fast as at the top even for very big
spreadsheets.
Change-Id: Id369b63e547aedf30c233f75c70d18f32e015edf
|
|
Cached row positions are invalidated when one of the following event
occurs:
- one or more rows are inserted
- one or more rows are deleted
- one or more hidden rows are made visible
- one or more visible rows are made hidden
- one row is resized
- optimal row height is changed
- the value of the PPTY parameter is updated
The same occurs for cached column positions.
Change-Id: Idf7b8cf1e694142e4fa0e1613d19ee9272b9a1be
|
|
Grid lines, cursor overlay, row/col headers are all computed by
summing up row heights / col widths converted to pixels.
On the contrary the document size was converted to pixel only at the
end after having summed up heights/widths in twips.
All that lead to have a document height/width greater than the
position of the last row/col, with the scrolling in online going
unplesantly far beyond the last row/column.
This patch change the way the document size is computed, so that the
spreadsheet height/width matches the position of the last row/column.
Moreover it exploits the cache-like structure for row/col positions
introduced in a previous commit.
Change-Id: I2e7b0e9601653856f88d1e5f9791aaec271592dc
|
|
ScPositionHelper provides the ability to insert (and remove) row-
position pairs where the position is in pixel and related to the
spreadsheet top.
In this way one can compute a new row position by starting from the
nearest row presents in this cache-like structure.
It offers also the ability to invalidate the cache by removing all
cached data below a given row or position.
This data structure can be used for columns, too.
Change-Id: I89c62b81fe9ae685ee84c33a128893c960ebd27e
|
|
Change-Id: I50cd9de5333f8fe0cbe542ebcf077411e9a959b3
|
|
Change-Id: Ice6758d8e9bc0ece57e038561376e7a6d67ab616
Reviewed-on: https://gerrit.libreoffice.org/35880
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
(cherry picked from commit 8d1a56c206e5c2ed6c331049198bb8ebc6176171)
Reviewed-on: https://gerrit.libreoffice.org/35904
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit 9700ba82ab9ffff07ae0c1ea1ca2a6e0d9a7347e)
|
|
These control characters are Writer implementation details and should
not be available via public interfaces.
This filter is also used by SwXTextRange::getString().
Change-Id: If656ee3d451dbefe2f7a905e8b63a44cdb787809
(cherry picked from commit ab4f53eaad0c064d9b2ff1c2cb20560f81ade1f7)
Reviewed-on: https://gerrit.libreoffice.org/35862
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit 5254a7d1cbf3f62c6664299752d2788bb4f2a0b4)
|
|
the shrinking patch a4dee94afed9ade6ac50237c8d99a6e49d3bebc1
causes problems, if the textboxes are anchored in the
footer. Therefore, disable it in this case.
For details, see comments in bug tracker.
Change-Id: I117a99041ff67c19a9de17803ff7864c62afdb50
Reviewed-on: https://gerrit.libreoffice.org/34517
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
(cherry picked from commit 80b9b6761e8cb974e0cdc0c7be0eb95f8745d86f)
Reviewed-on: https://gerrit.libreoffice.org/35844
(cherry picked from commit da18188c359dee813fa1d4c7000490f1512c277b)
|
|
The problem is that Writer's layout can't handle the case where cells
are vertically merged and the last row has a fixed height; the vertically
merged cell will grow up to the height of the other cells in the non-
fixed rows plus the fixed row height, but no larger.
So for now, avoid setting fixed row heights in this case.
(regression from d1278ef4849661b9ae0eb7aaf4d74fbf91ccaf11)
Change-Id: Iac3689e0bb0d5b8a62115ca0fb1f2c553a6e6bbc
(cherry picked from commit c382c998ffdaf80c10a3f078fb4f0a37224d1158)
Reviewed-on: https://gerrit.libreoffice.org/35960
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
(cherry picked from commit 7d7d21cfa53c8e80fd4dd0938579d8377da5a840)
|
|
Change-Id: Iac113433ac2317ddfebc68ed793c481384d56551
Reviewed-on: https://gerrit.libreoffice.org/35965
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
(cherry picked from commit 17c2f64e03476697d19f224fc9b08aa6cbc6cd03)
|
|
Change-Id: I8fd2896c8998e79794a0ccaae1c2442caf8b89ac
Reviewed-on: https://gerrit.libreoffice.org/35730
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
(cherry picked from commit b3d498755238cb0d9a7a3e33b6070c1e4c0e3482)
Reviewed-on: https://gerrit.libreoffice.org/35733
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
(cherry picked from commit 99744cb30435f2158d29967b77d08d0e4f79492c)
|
|
Same problem as commit 2aa20cfb7a11dd8d86372af4065a5887a0b752ca
Change-Id: I02160c53870a021c742babf358e0d6172557ef21
(cherry picked from commit cfaba15c589f882cc0bcce5cd07bdf3d30f547f6)
Reviewed-on: https://gerrit.libreoffice.org/35837
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(cherry picked from commit 81bf39616039280fc1f9b18db3ea6dc04ae9fc08)
|
|
Change-Id: Ie7c55c3a5c366618cafa51f9f1a102fb3cb26ec5
|
|
We know that the drawinglayer operates in 100th of millimetre, and that we
need twips for LOK.
Change-Id: I8813f936ab66eaca4d6b9c03341e090d703decb8
|
|
Based on Marco Cecchetti's research - thanks! :-)
Change-Id: I579b6c8e54311a679f5d684f7ca1e2d7373d0ec9
|
|
Assert two important properties:
- the pdf image is described using the form xobject markup (not the
reference xobject one)
- the form xobject refers to a vector image, not to a bitmap one
Change-Id: I94b88976c1e5392758d56254143fbeeeeba51412
Reviewed-on: https://gerrit.libreoffice.org/35901
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
(cherry picked from commit 932f6a8f37fbd99fc2ed16aa37966658d388c975)
|
|
Even if they are referenced multiple times. This is especially important
as objects can refer to each other, creating a cyclic graph. But it also
makes the output a tiny bit smaller.
Change-Id: I561ac319683a19a797282fe259cc68f3a4c50c3e
Reviewed-on: https://gerrit.libreoffice.org/35855
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
(cherry picked from commit 92ddc0409c8d3276183afdee543d28e1c307c2c7)
|
|
The whole point of "no reference XObjects" is knowing this vector markup
is supported everywhere, so no need to provide a fallback bitmap.
It was already unreferenced, but now it's not even written to the file,
making the PDF export result smaller.
Change-Id: Idf766c8eeded4235ebea49d13698a13c6b60f014
Reviewed-on: https://gerrit.libreoffice.org/35841
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
(cherry picked from commit 30102ded91b9ecfea172ffc6443154230ee37cbd)
|
|
Disable the "use reference XObjects" (old behavior) by default, but keep
it as an option in case someone wants it.
Summary till the help is updated: the old way is simpler code, so it's
always correct, but really only Acrobat supports that markup. The new
way is supported by all readers, but more complex, so it's more likely
it goes wrong.
Change-Id: I4769474f29d98412be496a0aa4e8254ae4f0919e
Reviewed-on: https://gerrit.libreoffice.org/35826
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
(cherry picked from commit 9c944b0d1bff9a0ab1b7e8454c9ac5e7194aa533)
|
|
To avoid repeting ourselves.
Change-Id: I39667620b9cf391251327c8f66ad8b9649ead36f
Reviewed-on: https://gerrit.libreoffice.org/35810
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
(cherry picked from commit f86c3fd8e95f378061d57b77d1c700e076996086)
|
|
Also fix confusion about dictionaries in arrays and arrays in
dictionaries.
Change-Id: I0d71d5796b1eb4f89e3fd9a5b1f807d2a7340a35
Reviewed-on: https://gerrit.libreoffice.org/35806
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
(cherry picked from commit 30608c66374f8effa9d534f7f9a22d41daa9770f)
|
|
When copying an array we're only interested in the start/end position of
the outermost array, otherwise only part of the array is copied.
Change-Id: I9f5cb5e3ed395142fd82db34e1153ddfdf9f0eb3
Reviewed-on: https://gerrit.libreoffice.org/35797
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
(cherry picked from commit 3ea5e3401e567bfe956817fd5abd17530da664f5)
|
|
The problem here was that while in general paragraph style / direct
formatting deduplication is supposed to happen in the tokenizer,
paragraph tab positions is an exception, and dmapper expects to see the
duplicated tokens.
Fix the problem by introducing a blacklist that contains tokens not to
deduplicate.
Change-Id: I1cca53e99cfdb082df389ff295f3447cc8f9d3b8
Reviewed-on: https://gerrit.libreoffice.org/35790
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
(cherry picked from commit fea174753b1c6b0882aebb044bf1a1eef6fa50e0)
|
|
When copying font definitions the dictionary has multiple values where
the type is a reference. Improve PDFWriterImpl::copyExternalResource(),
so that multiple references are copied correctly as well.
With this the bugdoc (from comment 5) text appears in the output.
Reviewed-on: https://gerrit.libreoffice.org/35760
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
(cherry picked from commit 2ba9d58d5978c94352c4c6cf9c47aa3de79d05fe)
Change-Id: I2343e616d8b36e3cdcbd4e713bd3f7fa7bce6d3b
|
|
...after a324099538916eae7f7239d32fd98ec8018cbb72 "xmlsecurity PDF signing: only
write incremental xref in an incremental update" inserted the 'if' before the
'while (!rStream.IsEof())'
Change-Id: Ib527894031f356c3d6df40b70259469ef4c338de
(cherry picked from commit e8aaaa52fa5abe4a70224ab6e6eee6265b0d61c8)
|
|
When copying objects referenced from the page stream support references
in any item value, not just for one single item key.
Also move the dictionary entry generator code to
PDFWriterImpl::copyExternalResources(), so other keys can be copied
without code duplication.
Change-Id: I4004e82014cec915c66a8a9d3aed2155fa2452ef
Reviewed-on: https://gerrit.libreoffice.org/35755
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
(cherry picked from commit 06d073695c764744d308c74f80c40a317255fc05)
|
|
So far only the dictionary and the stream of the object was copied, see
if it has an array, and take care of that as well.
Also check if the array contains a reference and act accordingly.
Change-Id: I7f3bb12ec0bbc6f6e1db4f43625c7768b862c895
Reviewed-on: https://gerrit.libreoffice.org/35744
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
(cherry picked from commit 044e8d795276cc495c1f796a14ad36e6a5f9cdb9)
|
|
Start copying referenced objects recursively, and also take care of
updating references to the object IDs as they appear in our output.
With this, the 4th image referenced from the PDF image has a correctly
updated reference in its dictionary's ColorSpace key.
Change-Id: I8b49701c1f60bd0ef5a097b24ce59164554c44fa
Reviewed-on: https://gerrit.libreoffice.org/35653
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
(cherry picked from commit f135a8bdeba15cf72dd31c7d613d335bbfc7017b)
|
|
With this the images inside the PDF image show up correctly.
Change-Id: I430502fb6ae9de8111dda7e67db33642ff263317
Reviewed-on: https://gerrit.libreoffice.org/35621
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
(cherry picked from commit 1f2bccf2d28d4257aa0e325658d35182367b59d9)
|
|
Since we want to avoid re-compressing the page stream create two form
XObjects: one that resets the graphic state to the default (e.g. line
width) and an other one that contains the original page stream as-is.
With this PDF images where the page stream is compressed are handled
correctly.
Change-Id: Ib44dae2e167e4d5604a0a3a3cf91e09795137343
(cherry picked from commit d0c24cbb027130f3781bfc3475dd225190afd560)
|
|
This gives correct result in very simple cases when the page stream is
not compressed and it references no other objects from the original
file.
Change-Id: I11ed50180a256bdb5c587fd8927d21c925100a4d
Reviewed-on: https://gerrit.libreoffice.org/35580
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
(cherry picked from commit d27818c1f34b01190bf419c34d6a174f3cad7894)
|