History

Khaled Hosny 3901e029bd tdf#104921: Cleanup Kashida insertion logic Communicate Kashida insertion positions in an explicit way. Rest of LibreOffice communicate adjustments to character widths (e.g. for justification or spacing) using so-called DX array. DX array is an array of absolute character positions (e.g. DX[n] is the position after character n from the start of the lines, and its widths is DX[n] - DX[n-1]). This DX array is modified also when Kashidas are inserted after a given character for Arabic justification, by expanding its width. VCL would use this to know where to insert the Kashidas and how many ones. But because DX array is used for both widths adjustments and kashida insertion, this turns out to be a source of bugs since VCL has tosecond guess the DX array to find which is pure width adjustment and which also involves Kashida insertion, and the heuristics it uses are fragile. This change adds a second array of booleans that records where Kashida is inserted and communicates it all the way from where Kashida insertion is decoded in Writer and down to VCL layout. This change passes the Kashida array only when it seems necessary (e.g. during drawing but not when measuring text since the DX array is enough in this case). Hopefully no places where Kashida insertion needs to be passed down were missed. A couple of glyph and layout flags that were used for old heuristics and no longer needed and are removed. This also fixes: tdf#87731 tdf#106309 tdf#108604 tdf#112849 tdf#114257 tdf#127176 tdf#145647 tdf#146199 Change-Id: I4ed0850ef2fdc3e9143341afac649e7e7d463c39 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138068 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>		2022-08-14 21:10:24 +02:00
..
inc
opengl
qa/cppunit
source
workben
CppunitTest_canvas_test.mk
Executable_canvasdemo.mk
IwyuFilter_canvas.yaml
Library_cairocanvas.mk
Library_canvasfactory.mk
Library_canvastools.mk
Library_directx9canvas.mk
Library_gdipluscanvas.mk
Library_oglcanvas.mk
Library_simplecanvas.mk
Library_vclcanvas.mk
Makefile
Module_canvas.mk
Package_opengl.mk
README.md
README.vars
StaticLibrary_directxcanvas.mk

README.md

UNO-based Graphics Backend

UNO-based graphics backend, lesser impedance to modern graphics APIs than vcl.

The canvas Framework

The canvas framework is the successor of the system GUI and graphics backend VCL. Basic functionality is available, supplying just as much features as necessary to provide a VCL-equivalent feature set (except proper BiDi/CTL support).

The canvas framework consists of the following two modules, canvas and cppcanvas. Additionally, a new generic graphics tooling is used (but not exclusively by the canvas, Armin's drawinglayer module also make use of it), which resides in basegfx.

The UNO API used by the canvas is primarily under css::rendering, with css::rendering::XCanvas being the central interface.

The slideshow Engine

The slideshow engine has replaced the former Impress-embedded presentation framework with a fully independent UNO component, and it is based on the canvas. Some features used there are only available from canvas, like double-buffering, and hardware-accelerated alpha-blending (currently not on all platforms).

Cairo canvas

Cairo canvas is one of backends of canvas component. canvas is mostly used for slideshow rendering and also for emf+ rendering. we hoped it will even be used by drawing layer, but it didn't happen (yet?) for API look at offapi/com/sun/star/rendering/, the implementation is in canvas and cppcanvas modules.

Cairo canvas backend uses Cairo library for rendering. Main advantage is support of alpha transparency and in some cases accelerated rendering.

The backend itself is quite old and stable, not many changes in that area lately, mostly changes for emf+ rendering, communication with vcl and bugfixes

Future Works

Look at Cairo canvas and situation when it is used (mostly slideshow).

TODO

There still might be more cases when we can save some roundtrips when exchanging data with vcl.