In OOo times, there'd originally been efforts to allow building on Windows with
MinGW. Later, in LO times, this has been shifted to an attempt of cross-
compiling for Windows on Linux. That attempt can be considered abandoned, and
the relevant code rotting.
Due to this heritage, there are now three kinds of MinGW-specific code in LO:
* Code from the original OOo native Windows effort that is no longer relevant
for the LO cross-compilation effort, but has never been removed properly.
* Code from the original OOo native Windows effort that is re-purposed for the
LO cross-compilation effort.
* Code that has been added specifially for the LO cross-compilation effort.
All three kinds of code are removed.
(An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing
--with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.)
Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568
Reviewed-on: https://gerrit.libreoffice.org/34127
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
GetHangingMargin() also returns offset for PostItPortion, assure
there is a hanging portion before using the value.
Change-Id: I750b8078fbd607d49f4bf5f76ea606fc36ea5c23
Reviewed-on: https://gerrit.libreoffice.org/33832
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
just the simple and obvious case for now, of a local var being allocated
and deleted inside a single local block, and the delete happening at the
end of the block
Change-Id: I3a7a094da543debdcd2374737c2ecff91d644625
Reviewed-on: https://gerrit.libreoffice.org/33749
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Seem UBSAN doesn't like my forced reinterpret_cast to set the Idles
Link in the Timer class. Now there are two possible solution:
1. convert all (DECL|IMPL).*_LINK call sites to use a Timer* or
2. split the inheritance of Idle from Timer again to maintain
different Link<>s and move all common code into a TimerBase.
While the 1st is more correct, the 2nd has a better indicator for
Idles. This implements the first solution.
And while at it, this also converts all call sites of SetTimeoutHdl
and SetIdleHdl to SetInvokeHandler and gets rid of some local Link
objects, which are just passed to the SetInvokeHandler call.
It also introduces ClearInvokeHandler() and replaces the respective
call sites of SetInvokeHandler( Link<Timer *, void>() ).
Change-Id: I40c4167b1493997b7f136add4dad2f4ff5504b69
This hang happened when the user executed Tools -> Language ->
Hyphenation -> Hyphenate All.
This problem is visible only if all of these conditions are met:
- a line in a paragraph has a word that already contains a soft-hyphen,
but not at the position where the automatic hyphenation would insert
it
- the last line ends with a word that can be hyphenated
- there is a fly frame in the document
In this case it happens during hyphenation that the layout has an
additional empty line at the end (which is removed by the time the
layout finishes), so we hit the case when SwTextFormatter::Hyphenate()
skips the "if( m_pCurr->PrtWidth() && m_pCurr->GetLen() )" block.
Normally hyphenation terminates when it iterates over the portions of the
line and no overrun nor any existing hyphen portion are seen, but in
this case that never happened. Fix the problem by terminating not only
when we reach the end of the portion iteration, but also when the
portion list is non-existing (has zero length).
Change-Id: I71d4b040a2d4692ae6eb92807dbbbb42b077a0f8
Reviewed-on: https://gerrit.libreoffice.org/33303
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
The commits: 1c1747ac13 and 4a410dd147
make trailing spaces and their highlighting compatible with the Ms Word.
The option is enabled by default for imported MS Word formats: .doc, .docx, .rtf
For the ODF files the option is disabled by default
Also it allows saving and loading the option state to the ODF UserData.
It may be manually set in Tools->Options->LibreOffice Writer->Compatibility
Change-Id: I5a86359c52d18e50bbb54b9f37c79b672591c369
Reviewed-on: https://gerrit.libreoffice.org/33046
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
TabOverMargin compatibility setting allows tabs placed beyond
the right margin to function where they are instead of using
the right margin as a hard limit. So far this has only been
effective for right tabs (the most logical tab to use at the
far right.
This patch adds support for center and decimal tabs also.
Left tabs are trickier, so they will be attempted separately.
CAVEAT: Basically all of this stuff tricks the layout
engine, so the amount of text allowed on a single line is still
"controlled" by the right margin. So, even though the extended
line could theoretically be very long, the amount of text still
must fit within the limits set by the right margin.
Thus large margins may cause wrapping in LibreOffice, instead of
disappearing off of the end of the paper as it does in MSWord,
and editing the text might get confusing - which matches the
experience in MSWord.
Change-Id: I1ff638eb3576ec221247e9a9823e7e082a1cba79
Reviewed-on: https://gerrit.libreoffice.org/32534
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
e.g. fdo80788-1.odt
Invalid read of size 2
at 0x3C031438: SwLinePortion::IsParaPortion() const (porlin.hxx:132)
by 0x3C05EC56: SwTextFormatter::BuildPortions(SwTextFormatInfo&) (itrform2.cxx:679)
by 0x3C05F2A2: SwTextFormatter::FormatLine(int) (itrform2.cxx:1550)
Address 0x3576189e is 30 bytes inside a block of size 40 free'd
at 0x4C2ED4A: free (vg_replace_malloc.c:530)
by 0x4E56939: rtl_freeMemory_SYSTEM(void*) (alloc_global.cxx:279)
by 0x4E56978: rtl_freeMemory (alloc_global.cxx:349)
by 0x4E5501B: rtl_cache_free (alloc_cache.cxx:1230)
by 0xDACE741: FixedMemPool::Free(void*) (mempool.cxx:49)
by 0x3C043AB8: SwTextPortion::operator delete(void*, unsigned long) (portxt.hxx:55)
by 0x3C043B05: SwHangingPortion::~SwHangingPortion() (porrst.hxx:98)
by 0x3C043F47: std::default_delete<SwHangingPortion>::operator()(SwHangingPortion*) const (unique_ptr.h:76)
by 0x3C044070: std::unique_ptr<SwHangingPortion, std::default_delete<SwHangingPortion> >::reset(SwHangingPortion*) (unique_ptr.h:344)
by 0x3C0888C3: std::unique_ptr<SwHangingPortion, std::default_delete<SwHangingPortion> >::operator=(decltype(nullptr)) (unique_ptr.h:280)
by 0x3C0888DB: SwTextGuess::ClearHangingPortion() (guess.hxx:51)
since...
commit a706bb06d5
Date: Wed Jan 11 14:26:47 2017 +0200
new loplugin: useuniqueptr: sw part 1
Change-Id: I614029474d684ddcccd4f4a5e9787fe6c19d8fd2
Use vcl::PDFExtOutDevData::SetScreenStream() for embedded media to make
sure that vnd.sun.star.Package: URLs don't end up in PDF out literally.
Acrobat Reader obviously doesn't understand that protocol.
Change-Id: I384891b3ef2dcea25bbf591bd210ccf899d30a61
Be explicit about the page number, this way a video on the second page
doesn't end up as an annotation for the first page. (In the Impress case
each slide is exported separately, so there this wasn't a problem.)
Change-Id: I83ba9cb4a3b2a6734bd88a138654e391199651c6
Reviewed-on: https://gerrit.libreoffice.org/32696
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
This is the sw-specific part only, the real work is done by the common
CreateScreen() / SetScreenURL() API added for sd earlier.
Change-Id: Ief9fd80082960ddd1f92f413eac79577621551ce
Reviewed-on: https://gerrit.libreoffice.org/32687
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
The problem was that the second fly frame was placed on the first page
initially, but after typing a character (which moved it to the second
page) and then undoing, it wasn't moved back.
Fix the inconsistency by handling the "fly frame takes all horizontal
space" case as parallel wrapping (which will result in no wrapping at
the end), this way the second fly frame appears on the second page both
initially and after editing.
As an additional data point, the DOC export of the bugdoc is now
rendered in Word the same way as in Writer.
Change-Id: Ifc9f17458ad0501b8ab6077e5a4998d48fd6f1d8
GCC 6.2.1 with -Og produces spurious -Werror=maybe-uninitialized
on variables that are assigned in conditions; perhaps it's better to
de-obfuscate the code if even GCC is confused about it.
Change-Id: Ib42290abd0e45158900b3d42e1b666fa4d0fa7f3
Reviewed-on: https://gerrit.libreoffice.org/31330
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
