Change-Id: I1999113b5c5ad533dc37ffd9adb9dfe346d5d749
Reviewed-on: https://gerrit.libreoffice.org/67493
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

this reverts

commit 3c4cfa20
Date:   Mon Nov 26 12:51:05 2007 +0000

    INTEGRATION: CWS fwk72 (1.195.14); FILE MERGED
    2007/09/10 14:55:01 mav 1.195.14.1: #i81437# do not allow to export to the file the document is based on

Change-Id: I8bf1524a8cc2d6d1911bdd228f33f1b7723e1d6e
Reviewed-on: https://gerrit.libreoffice.org/67491
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: I2310907071d2a8d63d78dbeb99022309870d5c34
Reviewed-on: https://gerrit.libreoffice.org/67489
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Regression from commit 50223ea6
(tdf#98987 sw: add AddVerticalFrameOffsets compat mode, 2016-03-31),
the problem was that vertical position of the shape was wrong after
mouse move, even if we attempted to take fly frames of the paragraph
into account. (Similar situation is when saving and loading the file;
which is much easier to test.)

Fly frames are created as the
text frames is formatted, and then SwTextFrame::CalcBaseOfstForFly() can
calculate the vertical offset correctly. But in the "move with mouse"
case SwToContentAnchoredObjectPosition::CalcPosition() was invoked by
the time the old flys of the text frame were already removed, but the
new ones were not yet added.

Solve the problem by formatting the text frame from
SwAnchoredDrawObject::MakeObjPosAnchoredAtPara() (if any of its validity
flags are set to false) -- this is expected to be safe, as the object
formatter is invoked by SwLayAction::FormatContent(), i.e. there is no
recursive SwFrame::Calc() call here.

Change-Id: I95851874e3da3f50f304421537c6743e04bdfc7b
Reviewed-on: https://gerrit.libreoffice.org/67490Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins

Change-Id: I52d75427fe30945293f347e3f49d21bc2016edae

Change-Id: I134101d1be5922051e34352331a49f5706030ff2

dropping the cached scaled bitmap when the bitmap
is accesed via BitmapAccessMode::Write for writing

Change-Id: Ib6539522944838238bd699ec3531039d21dc0f8b
Reviewed-on: https://gerrit.libreoffice.org/67459
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: I3a1072e6ededbd0322c4b1dcd0ef4b16ace219d1
Reviewed-on: https://gerrit.libreoffice.org/67478Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
(cherry picked from commit 32555d9b)
Reviewed-on: https://gerrit.libreoffice.org/67482
Tested-by: Jenkins

On the one hand, SvxZoomSliderItem/SvxZoomSliderControl as used by SwView's
SID_ATTR_ZOOMSLIDER support a range from MINZOOM (20) to MAXZOOM (600) (defined
in sw/inc/view.hxx).  Setting a zoom value outside that range for one causes the
DBG_ASSERT "Looks like the zoom slider item is corrupted" in
SvxZoomSliderControl::StateChanged (svx/source/stbctrls/zoomsliderctrl.cxx) to
fire, and for another (when setting a too small value) tries to assign a
negative value (which wraps around, and gets flagged by Clang's
-fsanitize=implicit-signed-integer-truncation) to sal_uInt16 nCurrentZoom at

  nCurrentZoom = nCurrentZoom - mxImpl->mnMinZoom;

in SvxZoomSliderControl::Zoom2Offset (svx/source/stbctrls/zoomsliderctrl.cxx).

On the other hand, SwXViewSettings' support of css.text.ViewSettings' ZoomValue
property allowed values in the range from 5 to 1000 (cf.
SwXViewSettings::_setSingleValue in sw/source/uibase/uno/unomod.cxx), and some
JunitTests actually set such values (10, 15) below the MINZOOM value of 20.

The incompatible 5--1000 range was there ever since
7b0b5cdf "initial import", but looks rather
random, so change it to match the 20--600 range instead.  (And lets flag this as
an [API CHANGE], to be on the safe side.)

One of the JunitTests files that needed to be adapted,
qadevOOo/tests/java/mod/_sw/SwAccessibleEndnoteView.java, oddly mentioned a
zoom value of 130% in a comment while using the value 15 in the actual code.
(And did so ever since the test code's introduction in
26ebdfc4 "NEW: initial version".)  Changing the
code to 130 would cause JunitTest_sw_unoapi_1 to fail in strange ways, with
disposed UNO objects, while changing the code (and comment) to 21 appears to
work.  Go figure.

Change-Id: Id944ffdce501448312e008436e7038bf2aec63ac
Reviewed-on: https://gerrit.libreoffice.org/67427
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

Since it is now possible to use C++14, it's time to replace
the temporary solution with the standard one

Change-Id: I871312c1077439377c67b76112f38b7019fa6fb1
Reviewed-on: https://gerrit.libreoffice.org/67376
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

Change-Id: I1d6a2b5d2b34dfd3356650a14cc853d00afbdda9
Reviewed-on: https://gerrit.libreoffice.org/67476
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

Change-Id: I362673c0dc6f687a7b9232b985243534a17285ad
Reviewed-on: https://gerrit.libreoffice.org/67479
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>

Change-Id: If4e07d497ead58a2ff58b5fdedd282b8784be421
Reviewed-on: https://gerrit.libreoffice.org/67435
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: I9b57e73303cb12e818cd761878d0c11c38f4cc3e
Reviewed-on: https://gerrit.libreoffice.org/67481
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>

it now looks old-fashioned hyphenated

Change-Id: I5b2b905277356c1b986f97de29f82ac1c21b1709
Reviewed-on: https://gerrit.libreoffice.org/66796
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>

now that we have it the same height as a statusbar

Change-Id: I0d5ee3f8dc57e94be5d45581bc4382e3448353c3
Reviewed-on: https://gerrit.libreoffice.org/67462
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

The former was of type sal_uLong while the latter has been of (potentially
smaller) type sal_uInt32 ever since at least
a02e8af5 "INTEGRATION: CWS hedaburemove01", and
Printer::GetQueueInfo (vcl/source/gdi/print.cxx) assigns from the former to the
latter (so potentially truncates).

But it appears the only non-zero values ever stored in the former are
QUEUE_JOBS_DONTKNOW (defined as 0xFFFFFFFF in include/vcl/prntypes.hxx, fitting
into sal_uInt32) and Windows-specific PRINTER_INFO_2W::cJobs (in
WinSalInstance::GetPrinterQueueState, vcl/win/gdi/salprn.cxx), which is of
Windows type DWORD, i.e., unsigned 32-bit, compatible with sal_uInt32.

So change the former (and QUEUE_JOBS_DONTKNOW) to sal_uInt32, too.

Change-Id: I0cc993d26831313b362cc31ee06fd879c854d146
Reviewed-on: https://gerrit.libreoffice.org/67468
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

...ever since at least a02e8af5 "INTEGRATION:
CWS hedaburemove01"

Change-Id: Ie363f02ed5b8ceaca4bd45f2bc1621e351a19ac9
Reviewed-on: https://gerrit.libreoffice.org/67467
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

Bug 46885 - LibO crash when creating chart with no cells selected

Change-Id: Iebe582863c2330579087d3d2743bca5d2d1676f6
Reviewed-on: https://gerrit.libreoffice.org/67472
Tested-by: Jenkins
Reviewed-by: Zdenek Crhonek <zcrhonek@gmail.com>

Bug 62349 - Calc crashes when a newly created chart copied to clipboard

Change-Id: I0627e2c86a7ce54ff0e84f8ebb3cdef1fce218c0
Reviewed-on: https://gerrit.libreoffice.org/67469
Tested-by: Jenkins
Reviewed-by: Zdenek Crhonek <zcrhonek@gmail.com>

Change-Id: I64a02ded0fea73d117527c62d91136b93ff31bcf
Reviewed-on: https://gerrit.libreoffice.org/67463
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>

...to f90e26b6 "tdf#107461: For Unix-like OS,
support file://<hostname>/... URLs" calling osl_getLocalHostname from
sal/osl/unx/file_url.cxx.

Change-Id: I2d9d3f8f7a1c7a1505dfafff0e60633b89f2de27

Change-Id: Ia74c43372b12eb71a8cc443de15458b374ee6b85
Reviewed-on: https://gerrit.libreoffice.org/67446
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>

cause the outer if is...

if ( pAny && ( *pAny >>= seqCoordinates ) && ( seqCoordinates.getLength() >= 4 ) )
{
	... nNumElemVert = seqCoordinates.getLength();
}

so this check is always true

Change-Id: I512b9440969775224c04d8566401b63f819711aa
Reviewed-on: https://gerrit.libreoffice.org/67464
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: I3f8fa4bafd5b3ff5eb549076db16cb73a5dde7e0
Reviewed-on: https://gerrit.libreoffice.org/67458
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>

Which was skipped before.

Change-Id: I7fcd5608a8cdbeea9ea15c9c9aa32c9020154750

Such that screenreaders don't announce them. To make this happen,
pass them as NonStructElement to PDF writer.

Change-Id: I94d52ee0207cd6362edabfb9b891faa7fe341543

implemented as described in
https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf#G21.1021281

Change-Id: I943c35cb8ee833ff46ff594e6b6c1025450b9ca4

pptx import seems little flaky in this regard, EE_PARA_OUTLLEVEL
isn't always set (no such problem with odp). Instead, we'll query
paragraph's depth and visibility of bullets/numbering.

Change-Id: Ia8cf6b7bb0e065a1378875442a99d79b006e2d77

The current tagged PDF export does not well support
quite some internal structures. This includes all
apps (Draw/Impress/Writer/Calc) and some areas.

-= AlternativeText ('/Alt'):

Only writer currently at least adds Title information,
but we also have Description (MS does add) and Name.
Target is to add this information when available to
content frames.
Writer did that by manually adding that tag using
PDFExtOutDevData::SetAlternateText, but only used
Title so far.
To make this work as broad as possible, better add
this to primitives. There is already a primitive called
ObjectInfoPrimitive2D that encapsulates any content
adding Name/Title/Description using GroupPrimitive
functionality.
Changed Writer to use that way. Draw/Impress already
uses it, all apps now use graphic paint using primitives,
so we have a natural target to encapsulate. Add support
to VclMetafileProcessor2D to interpret it and add
- if mpPDFExtOutDevData->GetIsExportTaggedPDF() - that
data using a combination of Name/Title/Description and
add using mpPDFExtOutDevData->SetAlternateText.
This works for Draw/Impress/Writer, but not for Calc
because Calc does not create more complex data structures,
so SetAlternateText does not work (see
PDFWriterImpl::setAlternateText for more infos).

-= Area tagged ListContent (use 'L', 'LI', 'LBody' PDF tags):

To support this in Draw/Impress, we can also use a similar
way to support in primitives. For this I evaluated how to
add needed OutlineLevel information to the existing (and
already used to write 'P') TextHierarchyParagraphPrimitive2D.
Added this and now ready to use in VclMetafileProcessor2D
::processTextHierarchyParagraphPrimitive2D.
Added now using the OutlineLevel information at the
TextHierarchyParagraphPrimitive2D. Made sure there are
fallbacks to unchanged old behaviour when no PDF export
or no Tagged-PDF used. Creating now '/L', '/LI' and '/LBody'
statements as tagged PDF wants us to do.
Exported PDF still works well while additionally a verifier
as 'PAC 3' shows the expected and wanted structure.
This will work now for any text in Draw/Impress and for
Draw-Objects using Lists in Calc. Need to check for direct
text in Calc cells and Writer - and guess how big the
effort would be for these to make it work there, too.

-= Area '/Artifact':

Target is to avoid too much ScreenReader hassle when
Impress uses Pictures/FillPatterns etc. in Background
- what means on MasterPage in Impress.
Experimented with different possibilities. Decided to use
existing StructureTagPrimitive2D and extend for info if
encapsulated data is 'Background' data -> on MasterPage.
Can be created in ImplRenderPaintProc in method
createRedirectedPrimitive2DSeque as needed by checking
for MasterPage member (remember: primitives need to be
as independent from model data as possible, never include
e.g. a SdrObject reference in any way).
Tried different ways to use this in VclMetafileProcessor2D
processStructureTagPrimitive2D, see comments there. Current
best solution is to just *not* create StuctureTag information
for these objects.

Change-Id: Ib2a578b02c1256758cda6d15ce37799803d8205c

... somewhere in a previous shared formula group, so for the new groups
after split the column is added to sc::RefUpdateContext::maRegroupCols
in ScColumn::UpdateReference() to setup new listeners later, and true
returned there, which also results in ScTable::SetStreamValid(false) at
the end, which in this constellation wasn't the case.

It may have been a reason that some documents have individual
unrecalculated results stored (i.e. values moved within ranges that a
shared formula group pointed to) that can be corrected by recalculating
after load.

Said to be a regression from

    commit 2f6a0685
    CommitDate: Fri Jun 5 16:22:38 2015 +0200

        tdf#90694 reset group area listeners when splitting group

but that only uncovered this misbehaviour.

Change-Id: I6b04b71898c3f1774452dd19790c208f3167d8eb
Reviewed-on: https://gerrit.libreoffice.org/67461Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins

I imagine it should have been seqPos-(idPos+2)

seems to be like this since the initial commit of

commit 091fe76b
Date:   Tue Jun 30 12:55:18 2015 +0300

    tdf#87348 implement mso-next-textbox vml-style textbox chaining import

Change-Id: Ic2f527ede2102c01c8589d58d8c705d59b0a6ffe
Reviewed-on: https://gerrit.libreoffice.org/67450Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

60db3d2c "dbu: Set Firebird to default in
wizard.." had done so only "..in case experimental feature is checked in", but
Firebird has been made non-experimental meanwhile as documented at <https://
wiki.documentfoundation.org/index.php?title=ReleaseNotes/6.2&oldid=169290#Base>.

<https://bugs.documentfoundation.org/show_bug.cgi?id=123099> "Creating new
'HSQLDB Embedded' database immediately brings up migration-to-Firebird dialog"
discusses that changing the default to Firebird may be beneficial, so lets do
that unconditionally now.

But 60db3d2c had apparently made a mistake,
setting the value returned from OGeneralPageWizard::getDatasourceName to
"sdbc:embedded:firebird" even though the corresponding "Connect to an exisiting
database" list in the new database wizard doesn't even support that (instead of
"sdbc:firebird:", which matches "Firebird File" in that list).  Fixed that now.

(Curiously, ODsnTypeCollection::getEmbeddedDatabase would read a
DefaultEmbeddedDatabase value from the configuration before resorting to the
hardcoded default, but `git log -SDefaultEmbeddedDatabase` makes it look like
there has never been any code to actually write that setting.)

Change-Id: I49b7430f5f8288a6a166ed9184cb438208d56ca1
Reviewed-on: https://gerrit.libreoffice.org/67449
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

one RemoveDrawObjFromPage is already null-deref protected,
do the same for the other

Change-Id: Ica5bb2df4a8dbffd8397df76b673adab75bb7aef
Reviewed-on: https://gerrit.libreoffice.org/67452
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Now it is "Word 2007-2019 Template" and not "Office Open XML
Text Template". Export implementation is focused more on
MS variant, rather than OOXML.

This is follow-up fix for 0932e4bb

Change-Id: I30b99bf73c20a3be27c62ca5d871f54b1032efc1
Reviewed-on: https://gerrit.libreoffice.org/67438
Tested-by: Jenkins
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>

Change-Id: I4ff8dcf928ebefed1eaeebdcdcfb90c56ddfd39e
Reviewed-on: https://gerrit.libreoffice.org/67440
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Probably helps VB6 clients.

Change-Id: I3a1072e6ededbd0322c4b0dcd0ef4b16ace215d1

Change-Id: Ia9e78c331d2cb711653ee3e64597ebf2824e0eeb

Change-Id: I14379c5732c1921b8f52293045d01acf99e0b840

Change-Id: I972f9446560cc8ac51031dbc36fc05d438d150e7