| Age | Commit message (Collapse) | Author |
|---|
|
LOK now opens PDFs as images using Pdfium,
which has a superior accuracy and support
to poppler, the default pdf reader.
Change-Id: Ifbbecf7f048f001836fb98886705cba47e6bed4e
|
|
This is used in parsing of meta Contexts across different
modules. This also involved moving to XFastParser for
parsing xml filters in sw, sd, starmath.
Change-Id: Ic663aaac6cb20ee8ce5b97cae87c93220f5a2929
Reviewed-on: https://gerrit.libreoffice.org/42989
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
This reverts the following commits:
commit 722f4e1d86710f2facd37d7e040df9e1fd585e26
tdf#104573 - Assertion failed: SolarMutex not locked
commit f04ec99f5e6a543b8191ced61db4710c3c0de356
tdf#104573 - Assertion failed: SolarMutex not locked
commit 71b1e3ff6374c23e65200d3bcafca387d29af04f
tdf#104573 - Assertion failed: SolarMutex not locked when trying
commit e794ce1eef6730e5a46d5fb0aa6db2895ede85e7
verify that we hold the SolarMutex when ref-counting VclPtr
IRC discussion:
<noelgrandin> sberg, maybe I should revert this whole "VclPtr assert" series, I don't have mental bandwidth to sort this out properly now
<sberg> noelgrandin, what I fear is that you'll end up adding lots of SolarMutex locks to small places, where the proper fix would be to add it further out; and once such a dreaded recursive SolarMutex lock is in place (but needlessly so, once the proper fix is done), it's hard to clean that up again
<noelgrandin> sberg, yeah, in that case I'll just remove all of this, leave it for another day
Change-Id: Ie4f84b72b79a1b7e80164b5c7693af398c2c569a
Reviewed-on: https://gerrit.libreoffice.org/31946
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If0c5a8c99f0f853c9ecad0f1a4a7299d69805b34
Reviewed-on: https://gerrit.libreoffice.org/31755
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...which contained the bulk of .cxx files that should logically go into
Library_pdfimport. It was likely (only) used so that check_targets
CppunitTest_sdext_pdfimport, Executable_pdf2xml, and Executable_pdfunip could
access the library's internals without exporting them. For the CppunitTest, use
the standard gb_CppunitTest_use_library_objects hack instead. For the two
Executables, make that _use_library_objects hack available for Executables, too.
(It is a bit unclear whether those two Executables are really needed, they are
only referenced from the dead dmake-based
sdext/source/pdfimport/test/testdocs/makefile.mk and from vcl/README,
respectively; but just keep them alive for now.)
Change-Id: Ia2478508de216678be7a2302aba0c48f80de9d91
Reviewed-on: https://gerrit.libreoffice.org/20645
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I27df97ab6e35b03dfe70c7a979dd06f977086069
|
|
|
|
This was a kludge from back in the day when pdfimport was an
extension and could not link against office libs.
While at it, fix mirror method to handle unicode surrogates
correctly.
Change-Id: I3582a7870efdfea50446d3604a185025b1d5a196
|
|
Change-Id: I54d8923ad315e8041fd3904da3a29f1a7a8c8b16
|
|
Change-Id: Ide652d073edc3321995b787b01ea9c0bf1920827
|
|
|
|
Naming convention for gbuild methods:
- "add" is used for stuff that is logically a part of the target
(i.e. not registered at the Module, but defined in the target's makefile)
- "use" is used for stuff that is logically a different target
(i.e. it is registered at the Module, has it's own makefile, may be
in a different module than the target)
|
|
|
|
|
