office-gobmx/sdext
Christian Lohmaier 0c4c84a14b makefile simplification: replace $(call gb_CustomTarget_get_workdir,foo)
…by a simple/static $(gb_CustomTarget_workdir)/foo

The build system has a lot of overly complicated leftovers from when it
was introduced and had not only deal with split repositories but also
had to coexist with another buildsystem. Along with lots of copy'n'paste
along the years the makefiles became hard to grasp for newcomers with
all our calls and evals.
As a first step to streamline that, the macros from TargetLocations that
simply prefix a static path to the argument (and similar of the same
kind) are a natural pick before simplifying the rules themselves/getting
rid of a bunch of eval statements.

Change-Id: Ia06dbbcd5d1994755a2ff05b84f72ccbc4e3cab5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167005
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2024-05-03 16:06:14 +02:00
..
inc
qa/unit
source use more OUString literal 2024-04-22 12:10:18 +02:00
CppunitTest_sdext_pdfimport.mk
CustomTarget_pdfimport.mk makefile simplification: replace $(call gb_CustomTarget_get_workdir,foo) 2024-05-03 16:06:14 +02:00
Executable_pdf2xml.mk
Executable_pdfunzip.mk
Executable_xpdfimport.mk
IwyuFilter_sdext.yaml
Library_pdfimport.mk
Library_PresentationMinimizer.mk
Makefile
Module_sdext.mk
Package_pdfimport_xpdfimport.mk Related: tdf#160260 Drop xpdfimport.err.pdf, let PDF import return false 2024-04-04 08:29:35 +02:00
README.md

Extensions for the Impress and Draw Applications

source/pdfimport/ - PDF import

Uses an external poppler process to parse and handle PDF import as draw shapes.

source/minimizer/ - Presentation Minimizer

Shrinks presentations by down-scaling images, and removing extraneous eg. embedded OLE content.

source/presenter/ - Impress / Presenter Console.

This couples to sd/ in rather strange ways. Its design is heavily mangled by an attempt to use only UNO interfaces which are highly inadequate. This leads to somewhat ridiculous situations. Activating in response to configuration keys (for example), and the XPresenterHelper interface inside sd/ used to create and manage windows.

The main screen uses a hardware-accelerated canvas (e.g. cairo canvas), while the entire secondary screen uses a VCL-canvas that is created in sd::framework::FullScreenPane::CreateCanvas().

The secondary screen contains 3 Panes which each have 2 XWindows for the border area & the actual content, and each content Pane is backed by a sd::presenter::PresenterCanvas that wraps the FullScreenPane's canvas and does clipping.