It's possible all children request 100% of space, need to scale down in
that case. This means that children other than the first one is now
readable in the layout result.
Change-Id: I86a05cd77510bbb6686a53e33f13a60034c8e8f6
Reviewed-on: https://gerrit.libreoffice.org/63037
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
The deadlock happens from time to time, when converting documents
containing OLE objects via remote UNO (from Java) -- after the
conversion, when closing the document.
The relevant stacktraces are:
>Debug.ListCallStack /ShowLineOffset /AllThreads
Callstack for Thread 8 (Thread Id: 32912 (0x8090)):
...
6 sal3.dll!osl_acquireMutex(_oslMutexImpl * Mutex) Line 75
7 [Inline Frame] emboleobj.dll!osl::Mutex::acquire() Line 56
8 [Inline Frame] emboleobj.dll!osl::Guard<osl::Mutex>::{ctor}(osl::Mutex &) Line 129
9 emboleobj.dll!OleComponent::OnClose_Impl() Line 1399
10 emboleobj.dll!OleWrapperAdviseSink::OnClose() Line 119
Callstack for Thread 11 (Thread Id: 21088 (0x5260)):
...
11 ole32.dll!00007fffc5e44e83()
12 [Inline Frame] emboleobj.dll!OleComponent::CloseObject() Line 1012
13 emboleobj.dll!OleComponent::Dispose() Line 484
14 emboleobj.dll!OleComponent::close(unsigned char bDeliverOwnership) Line 1463
15 emboleobj.dll!OleEmbeddedObject::GetRidOfComponent() Line 239
16 emboleobj.dll!OleEmbeddedObject::Dispose() Line 275
17 emboleobj.dll!OleEmbeddedObject::close(unsigned char bDeliverOwnership) Line 497
...
26 swlo.dll!SwXTextDocument::close(unsigned char bDeliverOwnership) Line 617
OleComponent::OnClose_Impl() taking a lock is fine, but
OleComponent::close() takes a lock and then later it still calls out
(via OleComponent::CloseObject()), which is a no-go.
Fix the problem by making sure that callers of Dispose() own no lock at
the time of the function call, and taking the lock in Dispose() only
after the CloseObject() call (which invokes event listeners).
Change-Id: I53befee21478188c7f79723b7d7596e66077d1c2
Reviewed-on: https://gerrit.libreoffice.org/63014
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
This reverts commit 343af46fc3 (ODT
filter: make sure we have a layout before export, 2017-11-29) as it
causes a performance problem with large documents (see bugreport).
I added it initially for the EPUB export, but there this is no longer
needed as commit 3ed8466b55 (EPUB export,
fixed layout: switch to a metafile-based approach, 2017-12-01) switched
to the better metafile-based approach.
Change-Id: Ie404e23db77b8ded1d29f42b6279a3cd06a574b5
Reviewed-on: https://gerrit.libreoffice.org/62924
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
The visible effect of this was that the 2nd level text nodes were
missing from the layout result.
The cause is that when it comes to counting nodes of a condition, we
assumed that the current layout node is a presentation of a model node,
but this is not necessarily true.
Fix the problem doing a "first presentation child of", then a "presentation
of" navigation in that case, which leads us to the correct model node,
so counting its children works.
(An alternative way of getting non-zero children would be a
"presentation parent of" navigation, followed by a "presentation of"
navigation, but that would lead us to the document root, so we would
count the number of 1st level elements, not the correct 2nd level
elements.)
Change-Id: Iccebe0e2e56b7acb7fbe2c38a7c9ebb2abb309b9
Reviewed-on: https://gerrit.libreoffice.org/62703
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
This would create a com.sun.star.drawing.DiagramShape, and work with
that, but nobody implements such a service.
Change-Id: Iaaed3ace95d86e52ba50e059ab89698197709189
Reviewed-on: https://gerrit.libreoffice.org/62671
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
This had (consistent) manual formatting before, but recently I broke it.
Change-Id: Ifd925797c5599aa55852b2e2fb7d16c5812cd159
Reviewed-on: https://gerrit.libreoffice.org/62673
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
The intention was to only conditionally warn. Thanks Noel for spotting
my mistake.
Change-Id: Iaa035dba1f834c13a179ef66c3f39777f3843bdb
Reviewed-on: https://gerrit.libreoffice.org/62641
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
How to reproduce the problem:
1) Create an ODT file which has an OLE object, where the native data i
an OLE2 container, containing a Package stream, containing a DOCX file.
2) Install some external application on Windows which registers itself
as a handler for the DOCX CSLID [ this is where writing a testcase for
this bug is challenging ].
3) Load the ODT file in hidden mode, e.g. connect to a
./soffice "--accept=socket,host=localhost,port=9999;urp;StarOffice.ServiceManager"
process from remote Java, load the file with Hidden=true in the
Arguments parameter of loadComponentFromURL().
4) Save it in a format that reads the replacement graphic of OLE
objects, like HTML or DOC.
Expected result: the replacement graphic is there.
Actual result: the <img> tag has no src attribute (HTML case).
The root cause is that in case the document is loaded in hidden mode
then the IDataObject::GetData() call in OleComponent::getTransferData()
fails, so the OLE objects enters a state where it no longer has its old
replacement graphic, but it doesn't have a new one, either.
Fix the problem by making this update more transactional in
svt::EmbeddedObjectRef::GetReplacement(), so the "document conversion"
scenario (load in one format in hidden frame, save in other format)
works.
Change-Id: I624c372baea56a85fb949bd99046f3af1f258c36
Reviewed-on: https://gerrit.libreoffice.org/62549
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
The motivation for remembering the text glyphs was to avoid repeated layout
calls during one sw layout run, this still preserves that optimization.
Approximate numbers for memory usage after importing the bugdoc finished:
- old: 401MB
- new 366MB (91% of baseline)
Change-Id: Ie960c606a8246c9c696745b2dcc9a49c3c570c07
Reviewed-on: https://gerrit.libreoffice.org/62496
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
Finally the "parent text" of the test document now has correct width.
Change-Id: I05c552dda66ad91f19cfc335b464549920269f69
Reviewed-on: https://gerrit.libreoffice.org/62395
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
This would create a com.sun.star.drawing.DiagramShape, and work with
that, but nobody implements such a service.
Change-Id: I32a63dd258a5f168e37c5926a832dadd45c2b179
Reviewed-on: https://gerrit.libreoffice.org/62371
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
The "Vertical Box List" preset in PowerPoint contains two linear
layouts, the inner one nested in the outer one. All the constraints are
stated on the parent layout. This commit doesn't actually read those
constraints yet, but adds infrastructure to look up parents of layout
nodes and also to get the constraints of a layout node.
No functional changes intended.
Change-Id: If844d17a90f8f180a9d21245249a2744bea32b31
Reviewed-on: https://gerrit.libreoffice.org/62367
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
Would be "HTML" by default, but reqif-html is mostly very simple
documents and the custom page styles is unexpected.
Change-Id: I3f1b293bcd074305cf5cc87f03248e934d5fac4d
Reviewed-on: https://gerrit.libreoffice.org/62317
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
Less code and other classes in the same header already do this.
Change-Id: I8a64cabcdb4b95acb7e2f55ec371568702d9c331
Reviewed-on: https://gerrit.libreoffice.org/62333
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Smaller width only makes sense in the fromL/fromR cases, I think.
Change-Id: I21c643b90556e47593b62abc2466e808d1ef31e5
Reviewed-on: https://gerrit.libreoffice.org/62024
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
This way at least something shows up in the import result. Far from
perfect, though.
Change-Id: Iae5a073d458598e7b5059ebdf435d50ce7c7df80
Reviewed-on: https://gerrit.libreoffice.org/61925
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
That dialog is counter-productive if you develop that feature itself.
Change-Id: Ia635a2ff0ecc29a0d11be5c621a7c2a76469f9ba
Reviewed-on: https://gerrit.libreoffice.org/61880
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
To silence this warning:
/usr/lib/python3.6/site-packages/pycodestyle.py:2190: UserWarning: [pep8] section is deprecated. Use [pycodestyle].
warnings.warn('[pep8] section is deprecated. Use [pycodestyle].')
Change-Id: I0a2f9b266562a797d1625b3c50261e7e43315fb7
Reviewed-on: https://gerrit.libreoffice.org/61827
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
RTF export at the moment exports children of group shapes as a flat
shape list. This means that the order inside the group shape is not
relevant for the toplevel ZOrder, so just don't write it.
Change-Id: I870707cb28c2f177c0e5d9cf5328260e76b661f3
Reviewed-on: https://gerrit.libreoffice.org/61805
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Last usage was removed in commit
45c753aff6 (svx: pdfium's
FPDFImageObj_GetBitmapBgra() is not needed after all, 2018-09-28).
Change-Id: I2412fa24859ad5bcd3ced634d3c4f41d2f35aebe
Reviewed-on: https://gerrit.libreoffice.org/61599
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
This helps not storing pre-computed vcl text layouts which are most
probably never re-used anymore.
Approximate numbers for memory usage with 10 column resizes for the
bugdoc:
- old: 310MB -> 454MB
- new: 309MB -> 310MB
Change-Id: Ifb88b88e1bffe2c2670089930fc2d22ff19576ce
Reviewed-on: https://gerrit.libreoffice.org/61562
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
The old code only worked when left and first margin was 0; feed the
relevant margin to SwTextFormatInfo, so SwTextFormatInfo::GetLineWidth()
can compare against the right rectangle.
This way TabOverMargin compat flag results in layout that matches the
Word behavior for all 3 bugdocs from the bugreport.
Change-Id: I6f81ad33b14e95ba4213c8956b3a9790ba6eee84
Reviewed-on: https://gerrit.libreoffice.org/61518
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
What happened is:
- the paragraph was split into two lines, at the correct position
- but then the first line checked how wide the tab portion can be, and
there it concluded that it has a lot of space, so the tab portion was
1418 twips wide, instead of the expected "almost zero" 69
The root of the problem was that first the text break was determined
using the TabOverMargin rules (more horizontal space), but later a check
validated the result ignoring the TabOverMargin flag (less horizontal
space). Fix this inconsistency by using GetLineWidth() in
SwTextPortion::Format_() instead of manual calculation.
Change-Id: Iaa7144341dfeaa8d177716dd87165598f11fd573
Reviewed-on: https://gerrit.libreoffice.org/61403
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
In case an ODT document has the usual layout compat flags enabled (by
the DOC/DOCX/RTF imports) to emulate Word behavior, then it's expected
that Word will lay out the resulting ODT document similar to Writer.
This works most of the time, but in case exact spacing matters, it's
important that PrinterIndependentLayout is not disabled, as that doesn't
match the Word default and will result in mismatching Writer vs Word
layout.
Change-Id: I0fbe110a6417ffa5d919fb81236a60bfa1fc30f5
Reviewed-on: https://gerrit.libreoffice.org/61352
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
Not just font color, anything defined via list styles were not imported.
Change-Id: I95e6fc52e30a09ff93fb55d0836e45e177a7b099
Reviewed-on: https://gerrit.libreoffice.org/61230
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
Commit 708d1c5ab2 (sc lok: emit
RowColumnHeader info in twips, 2015-11-02) improved precision of the
twip -> pixel conversion ratio, but ignored the detail that limited
precision used to silence cumulative errors that appear with larger
precision.
The original use-case was better precision of row/column headers for the
LOK API, so keep that as-is, but go back to the original behavior on the
desktop.
Change-Id: Ide169ab1745a9a9299caf3334559884ff7223cbe
Reviewed-on: https://gerrit.libreoffice.org/61219
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Thanks Michael Stahl for the conference talk that was the input for
these.
Change-Id: Ia48248f4739218ee7832559353aab06183a934d7
Reviewed-on: https://gerrit.libreoffice.org/61079
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
Given that we do check for the different formats just below anyway.
Thanks Ashod Nakashian for pointing this out!
Change-Id: Ie481f6f3fa66ee182668bd6ea7171da2a04cca9d
Reviewed-on: https://gerrit.libreoffice.org/61078
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
Deciding when to and when not to deduplicate repeated direct formatting
of paragraph / character properties is stricky, this bug is about a case
when deduplication should happen and did not, since commit
1970a68627 (tdf#113408 RTF import style
dedup: separate paragraph and character handling, 2017-10-31).
Especially that deduplication works in both directions: it should remove
properties which are duplicated and also should insert explicit default
values for not repeated properties.
Fix the problem by making the getDefaultSPRM() aware of the context
(which style type it deals with), and then by making sure that only
default properties relevant for the given style type are inserted.
Change-Id: I35b6599cc47fa51b8754fd921c61a3b31a283547
Reviewed-on: https://gerrit.libreoffice.org/60946
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
Normal shapes have a TextFitToSize property for this, but table cell
content has to be scaled manually, as the rendering has no automatic
support for them. Luckily the file format has the info we need to scale
at import time.
Change-Id: Ibbcc4b8685995261536cce88b8c0774e148f708e
Reviewed-on: https://gerrit.libreoffice.org/60880
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
Longer term the core Impress shape has to be improved so that it can have
text in multiple columns.
Shorter term, map text with multiple columns to table shapes, that gives
correct layout in many cases and requires changes to the import filter
only.
Change-Id: Id7942b16882ab1f083ded2f0e577e8c9e128697c
Reviewed-on: https://gerrit.libreoffice.org/60859
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
This is effectively dead code as commit
547217ecf2 (Document seemingly dead
QuickDiagrammingImport, QuickDiagrammingLayout, 2013-06-03) found, so
the primary motivation is to just get this out of
oox_component_getFactory().
Change-Id: Ibfee57202f0a3b02847b1298ce8895c8cf312322
Reviewed-on: https://gerrit.libreoffice.org/60840
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Commit 2d1e4290a9 (Merge Gentoo patches
from old build and downstream repositories., 2011-03-13) mentions this
was necessary for libxml-2.7.8, but xmlsec already depends on 2.8.0 and
the same "extern block starts before the include list" pattern is there
in every other xmlsec header, so the patch was incomplete anyway.
Change-Id: I33fadcb3e5583266a37cf7f240b27b2df1544040
Reviewed-on: https://gerrit.libreoffice.org/60782
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Just do the minimal fixing, a follow-up commit should clean up the
copy&paste coding that happened here in previous commits.
Change-Id: I44306e2fee57d55997414e62120c7e5037f306fb
Reviewed-on: https://gerrit.libreoffice.org/60757
Tested-by: Michael Stahl <Michael.Stahl@cib.de>
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Allows dropping all the backports, so only one custom API patch remains.
Change-Id: I13dc4f62be86d0859862cbd95bb14e07bbcf53d6
Reviewed-on: https://gerrit.libreoffice.org/60697
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
This was a problem since commit 29d4ecf323
(tdf#115574 sot: fix Excel -> Writer paste, 2018-03-29), the root cause
seems to be that (older?) Safari provides RTF clipboard content which
simply doesn't contain the images.
Just to back to the old behavior on macOS for now, hopefully the
problematic RTF producer will go away in the long run.
Change-Id: I5c40b28671978cfbf8593f1cc9775985dffc5030
Reviewed-on: https://gerrit.libreoffice.org/60641
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
The interesting part of the layout of page 2 is:
- frame #40 is a section frame with a text frame which is in a list
("A")
- frame #48 is a section frame after that, with the same top=19213
Given that frame #40 has height > 0, they overlap when the page is
rendered. What happens is:
- frame #40 grows
- there are other section frames between #40 and #48 in-between, but
they don't have an SwSection
- these frames are skipped
- then the position of #48 is invalidated
So the next time we calculate the position of #48, we look the last
skipped (previous) section frame (which still has top=19213, since its
position was not invalidated above), and since its height is 0, we
conclude that our current top=19213 is valid after all.
This is like this since commit 84a3db80b4
(initial import, 2000-09-18), so leave the code there that invalidates
not only the next frame, but all the way down to the first
non-SwSection-less-SwSectionFrame. But instead of just invalidating the
last frame, invalidate the in-between SwSection-less-SwSectionFrames as
well.
In practice this did not cause a problem in case the document has no
layout cache. If it does, then the frames are created on pages hinted by
the cache, then later moved to their final place. In practice this bug
was visible only in this later case. (I.e. such a layout cache can be
only created if the machine that saved the document last time does not
have the fonts needed by the document installed; and then the document
is opened on an other machine which has those fonts.)
Change-Id: I02ae9f63d0b4b5e9d014df53ed2cf21a04b15090
Reviewed-on: https://gerrit.libreoffice.org/60502
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
This is effectively dead code as commit
547217ecf2 (Document seemingly dead
QuickDiagrammingImport, QuickDiagrammingLayout, 2013-06-03) found, so
the primary motivation is to just get this out of
oox_component_getFactory().
Change-Id: If0a585c2fc4b87ceb00e6f772fef2ac65d10dc67
Reviewed-on: https://gerrit.libreoffice.org/60470
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Otherwise it's not easy to see which frame position was invalidated in
SwFrameAreaDefinition::setFrameAreaPositionValid() in a SAL_DEBUG()
statement.
Change-Id: I5771a81b98524bbce6557653a1a366e7a91c583e
Reviewed-on: https://gerrit.libreoffice.org/60443
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
Otherwise we could break some external code for no good reason.
Change-Id: I01b1e266425688d3d4b5293c0f8609d78c6b7f2f
Reviewed-on: https://gerrit.libreoffice.org/60331
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
osl::FileStatus::getAttributes() and osl::File::setAttributes() doesn't
preserve all the necessary file properties (at least "Hide extension" is not
handled), so always copy on macOS instead.
Change-Id: I529467cc3d432d04e593f936c13ed4656a18150c
Reviewed-on: https://gerrit.libreoffice.org/60294
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Number of GenericSalLayout::LayoutText() calls during Writer startup at
this call-site: 1068 -> 614.
Change-Id: I3bef56e550294a6b2c9fe73c0c6531249c9f1f30
Reviewed-on: https://gerrit.libreoffice.org/60164
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
PowerPointImport_getSupportedServiceNames() was copy&pasted from
oox::core::FilterBase::getSupportedServiceNames(), so it can go away entirely.
Change-Id: Ia6352cea1c2d65ba94cae66b500de951d82f455a
Reviewed-on: https://gerrit.libreoffice.org/60124
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
Number of GenericSalLayout::LayoutText() calls for each & every menu
item till a Writer document is opened: 3 (before) -> 1 (after).
Change-Id: I08a3d174bf15bafbcbce612712f2ab773cd5e085
Reviewed-on: https://gerrit.libreoffice.org/60045
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
osl::File::move() would not follow symlinks for the target, so don't
move the file in that case.
Change-Id: I907e1ba8db04dad670c884ea0283947f953117da
Reviewed-on: https://gerrit.libreoffice.org/59949
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
This builds on top of commit 436b829f5b
(sw: save one vcl layout call in SwFntObj::DrawText(), 2018-08-16), but
now layouts are shared not only inside SwFntObj::DrawText(), but also
between SwFntObj::GetTextSize() and SwFntObj::DrawText().
To get there, create an SwFntObj cache member that stores already
calculated vcl layouts. SwFntObj already derives from SwCacheObj, so no
need to explicitly expire this cache member.
Total number of GenericSalLayout::LayoutText() invocations go down from
8 to 5 with this when pressing a key in Writer.
Change-Id: Ifbe84a5c00025604f9c1331b56074b3dc27864b5
Reviewed-on: https://gerrit.libreoffice.org/59879
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
I suppose if language is set, that happens in the wrapping ReqIF
document, not in the XHTML fragments.
Change-Id: I970c3810b7f02bbafc37dd85e095b254cc651330
Reviewed-on: https://gerrit.libreoffice.org/59810
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
It is possible that we not only have a dummy OLE object, but both the
replacement image and the native data is missing. Handle these enough so
that we don't give up exporting the document and also produce valid
output.
Change-Id: Ia973ecfbfb7e8fdecdc831b29d3a82c988ed7ea5
Reviewed-on: https://gerrit.libreoffice.org/59806
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
Fixes the problem that e.g. this code:
OUString str;
str += "";
is marked as a compile error, when clang would still work with c++11,
but the tree is configured for gnu++17.
Change-Id: Id60c0cf4b8c693b534f16ba813cf01a4bad7e560
Reviewed-on: https://gerrit.libreoffice.org/59746
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
But only for XHTML, HTML stays unchanged to be in sync with web
browsers.
Change-Id: I3a1cf6651dab565bafece68963acb112ae715cdd
Reviewed-on: https://gerrit.libreoffice.org/59727
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
The too aggressive error handling in commit
fb04780cf8 (tdf#116117 sfx2 store: don't
inherit temp file permissions when renaming, 2018-03-12) means that if
the file is already there, then we don't try to stat() it; even if there
is no problem with that.
Change-Id: Ie0b9084064834e339bcae3ad7b4a35c54cb9d3c2
Reviewed-on: https://gerrit.libreoffice.org/59684
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
Type "🐶" into Writer with e.g. the Liberation Serif font, glyph
layout doesn't execute, a literal 0 glyph id is rendered.
Fix the problem by returning the glyph items (to be inserted into a
cache) after handling glyph fallback.
Change-Id: I928b0087de309dbe04936c6e7732d79bec541596
Reviewed-on: https://gerrit.libreoffice.org/59665
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Miklos Vajna