| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Change-Id: I6d5a952901648e01904ef5c37f953c517304d31e
|
|
|
|
| |
Change-Id: I22d22a924d33b91ba6894857ce56b0d920102b4b
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we always exported the text of the shape itself. Bring the
VML export in sync with the drawingML export, where we only do that if
the shape doesn't have an associated textbox -- if that's the case, then
export the textbox's text instead.
CppunitTest_sw_ooxmlsdrexport's testFdo69636 is a reproducer for this
problem, the VML assert failed because of the lack of this.
Change-Id: Icb236579da4e3b74e983a95aa5675fed7862d1e1
|
|
|
|
| |
Change-Id: I69aa440ed4ef13e60251bf1aa019208b79b317d2
|
|
|
|
| |
Change-Id: I03a26d49210c3dfe89abd31e5c754fafe2b7acee
|
|
|
|
| |
Change-Id: I4caf4b2ac028629c6ecbd42084346623192df09e
|
|
|
|
|
|
|
| |
especially because most of them don't handle intercepting text getting *pasted*
into them right, so start with the one which does that right.
Change-Id: If6770798872ed3c72c469656ebf0d4fd76d2171d
|
|
|
|
| |
Change-Id: I0ebb18a8ad2fec70ced535200139e5cd34822c84
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the OutputTextNode, the text data is postponed when the in case of
NOT_PROCESSED state of fly frame. This text data is never been processed
later.
When the text data is postponed we should write this before processing
the next text node.
Change-Id: Ib8d5fdcf8dcfb9ff394d32103502150e08bbd521
Reviewed-on: https://gerrit.libreoffice.org/9737
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
|
|
| |
Change-Id: If06465ebad4083b8cdcd102ed0bbc6f61e78410f
|
|
|
|
|
|
|
|
|
|
|
| |
adjust condition to trigger sort of bookmarks in order to avoid serious
performance decrease
Kudos to Ariel for his analysis
(cherry picked from commit 6895a55d74fe6a3b70ba15f77050652d3afee821)
Change-Id: Ic72b0a07556ec85a6ee2568f814b8bcfaaabe42e
|
|
|
|
| |
Change-Id: I62f0159bec97c6c7a2285509b0662125f46ed480
|
|
|
|
| |
Change-Id: I6737d75c70c36b19c5bec075f6f82f159ef00d2d
|
|
|
|
| |
Change-Id: Ie3b7099aea1d473cca88c4904683234408920100
|
|
|
|
|
|
|
| |
Change-Id: Iaaa32bd5723ae45099d0fb670b207fc64c46d306
Reviewed-on: https://gerrit.libreoffice.org/9780
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
|
|
|
|
|
| |
gb_Library__get_name was forgotten in
1817366cb5f61337b34b5284615d3d4e0a8aa68a
Change-Id: I42592d70455b9c695879d7fa20881c77a1ca2066
|
|
|
|
|
|
| |
and strip away some stuff in rsc that should now be dead
Change-Id: I6411e706c50dff299099680f1f942bf61c4e79f2
|
|
|
|
| |
Change-Id: I1c87406d9b23e36d35e2ef2e62f9f7b4d209e381
|
|
|
|
| |
Change-Id: I1f1db08447006515e7e6842792241aca992984c0
|
|
|
|
| |
Change-Id: I32d1e15cb9f050e3cd05babbd2f21c57f3ccb5e7
|
|
|
|
| |
Change-Id: I1f8737bbe128c747c84c67e8ba8000ecef1ed4f7
|
|
|
|
| |
Change-Id: I7e4fffabf6b1d96a458a3afd141f86d0e4565230
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... for clipboard documents
- assure invalidation and updates on code to update fields
(cherry picked from commit 3d4d98d4d98bc62474ec295cdc4d070a01dcac13)
The substantial bug was already fixed years ago by commit
9519deda120b73b72e75d89c3b2ae3d66220ec2d
Conflicts:
sw/inc/txtannotationfld.hxx
sw/inc/txtfld.hxx
sw/source/core/crsr/crstrvl.cxx
sw/source/core/txtnode/atrfld.cxx
sw/source/core/txtnode/thints.cxx
Change-Id: Ib4965c5d443b60bab11bad1a9249fc6547976a3c
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Shapes may not have a unique name, but TextFrames always have. So in
order to be able to link shapes with textboxes, provide a ChainName
property that's the name of the underlying TextFrame. This kills two
birds with one stone:
- we can have a unique name for each shape
- the names can be used for TextFrame linking, as they are valid
TextFrame names
Change-Id: Ie96f267d392d9fe5388c5eacff9b873f1639054c
|
|
|
|
|
|
|
| |
At the moment it's only possible to set this property, and it only sets
the same property of the underlying textbox, if there is any.
Change-Id: I9f168f69a8e92a1b26f21e653a05c97e2e32297c
|
|
|
|
| |
Change-Id: I26e1e0f66dad5ed4e8351fc7509449b312559166
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This method calls DocxSdrExport::writeDMLDrawing(), which may call back
WriteTextBox(), which may call WritePostponedDMLDrawing() again. The
result is that we try to flush drawings inside a shape which were
postponed outside of it. Luckily, StartRunProperties() asserts this, so
instaed of silent corruption, such an attempt crashes.
Fix the crash by saving the postponed drawings on the stack, and
restoring them after the shape export finished.
CppunitTest_sw_ooxmlsdrexport's testAnchorIdForWP14AndW14 is a
reproducer for this problem (when shape with text is imported as shape
with textbox).
Change-Id: Id5aeda33472655697717401c24dd54e7efabacd9
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RTFSdrImport::resolve() is called for \picprop and creates an XShape
that is stored in RTFSdrImport::m_xShape and also
DomainMapper_Impl::m_aPendingShapes;
later RTFDocumentImpl::resolvePict() completely ignores that XShape
and creates a new one, which is also inserted in the document;
the first XShape is effectively leaked.
Try to avoid that by re-using the exising m_xShape in resolvePict().
Not sure if there are any problems with doing this, it's all a bit
confusing.
Change-Id: I98456242acb0766f547eb8f7d877f51d53323f3a
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the shape properties are inside \picprop destination, don't set
shapeType.
(regression from 9f1f7199736e2ae07b34849ba66f61a1ef5782e8)
Actually this does not fix the root cause, this is just a work-around,
the extra shape is still inserted but it's invisible now.
Change-Id: I6cf093de2a5657533f393863ed8010ae083bec16
|
|
|
|
| |
Change-Id: I89ea074bacf7884fe8b8471cfd208f643326a7e1
|
|
|
|
| |
Change-Id: I9e2fd1249061fcf386a8812a42450e52d37bdc5c
|
|
|
|
| |
Change-Id: Icf80cff1f68e85bf9103aedc95ccca80e2d32681
|
|
|
|
|
|
|
| |
I can see nowhere that m_pHScrollbar or m_pVScrollbar are
set to NULL, deleted yes in the dtor, but nowhere NULLed.
Change-Id: I3012be6de1117757237884deebacc9e0e29dc7a7
|
|
|
|
|
|
|
|
|
|
|
| |
The TextRange property of a shape is its anchor position: if that's
adjusted, then also set the textbox's RES_ANCHOR to the new position.
Without this, e.g. shapes anchored in headers have their textboxes
anchored in the body text, CppunitTest_sw_ooxmlexport's testfdo78420 is
a reproducer.
Change-Id: I83ed09875c3f0360c581c331507ad2b9d05ffb3a
|
|
|
|
|
|
|
|
|
|
|
| |
Also, let the new SwTextBoxHelper::restoreLinks() restore also the
RES_CNTNT of the *old* draw formats, not only the link between the new
draw and fly formats.
This allows properly preserving the link between draw and fly formats,
when they are in the header (and so copied in and out variously).
Change-Id: I101ff06533e2ea27abea8bed171ed69c9649ebe8
|
|
|
|
|
|
|
|
|
|
|
| |
In case a shape (has a draw format) has a textbox (RES_CNTNT of the draw
format), then that's just a pointer to that content, but the draw format
doesn't own it: the matching fly format does. So ignore that content
when deleting the layout format in case of draw formats: that ensures
when both the draw and the fly format is deleted, deletion is only
performed once.
Change-Id: Idb4bb19130a6b9acd8f8d3710b9982801b416dda
|
|
|
|
| |
Change-Id: I6a759eb3c5bff4dcf4603d648053e17a6d4ff837
|
|
|
|
|
|
|
|
|
|
| |
"LC_ALL=C make CppunitTest_sw_rtfexport" was still failing after
e47a02b1524061143d8e77a54eb95c77f2e6dae2 "fdo#77979: sw: RTF export: write non-
ASCII font names encoded," so for each given eTextEncoding determine a Windows
charset that can at least encode the font's name, and not only for Unicode-
related eTextEncodings.
Change-Id: If547566bb0cffc60411d8f667d76749a904f7a3f
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: Many classes inherit directly from std::vector
See comment#6 by kendy for more details.
Solution: Removed class SwpHstry altogether and moved its
destructor's functionality to SwHistory's destructor.
Changed type of m_SwpHstry from SwpHstry to vector<SwHistoryHint*>
Change-Id: I32a7e111fef7c5e7b83ecee6469e173b5a21a5bf
Reviewed-on: https://gerrit.libreoffice.org/9725
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
|
|
| |
Change-Id: I986805143615f053b918fb1e64b0b24d6f76f2de
|
|
|
|
| |
Change-Id: I1485d646171b08f709767debfe583f90426d5dfd
|
|
|
|
| |
Change-Id: I1bb293567cf6e6437d1ac1f257b25d7de1d0ac75
|
|
|
|
| |
Change-Id: I2b8ac2204ec4f47dcce033da18e31b8bb5285552
|
|
|
|
| |
Change-Id: I5209538e50ca92a2993520fa68446f5287771d93
|
|
|
|
| |
Change-Id: Iea5f79fb12ac86d4348f46f8ad93a13aaf0f7eb6
|
|
|
|
|
|
|
| |
Change-Id: I1a187426ae41b9398c062f3c4998363b073e80f1
Reviewed-on: https://gerrit.libreoffice.org/9744
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
|
|
| |
Change-Id: I8fc9d0eeab6f63be4c815adcbd092d5ff2a96586
|
|
|
|
| |
Change-Id: I63f7914b52af51b55a51d39953a1ee58636243a3
|
|
|
|
| |
Change-Id: I64cf70cf7f1f77c38a8a4804b705ce8a0441e487
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently font names like "微软雅黑" (Microsoft YaHei) are
written as "????" in the RTF export; to avoid that, set the \fcharset
of the font entry to something that at least is able to encode
the font name and alternate name.
This requires a new function since the existing
rtl_TextEncodingToWinCharset was changed in
b88fe998ce8c80d7629fe70118311096615d959d to return "default" 0x01
(for OOXML) which is quite unhelpful for RTF.
This is not entirely satisfactory, as of course that is no guarantee
that the encoding can represent all of the actual text that has the
font applied; hence there are some \'3f in the fall-back encoded text
of the heading of the bugdoc, which indicates that the detected
Shift-JIS is insufficient and GB-2132 would be required; but it's not
obvious how to do better here without iterating over all the text
twice, and that still leaves the possibility that all text that has a
particular font applied cannot be represented by a single non-Unicode
encoding.
But since we always write text as the \u Unicode + legacy fall-back,
this should not be a big problem since modern RTF readers will simply
read the Unicode.
Change-Id: Ie6a42294c501d014dd9f0df82638519412ca19bb
|