3901e029bd
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> |
||
|---|---|---|
| .. | ||
| doc | ||
| inc | ||
| qa | ||
| sdi | ||
| source | ||
| uiconfig/ui | ||
| util | ||
| AllLangMoTarget_svx.mk | ||
| CppunitTest_svx_core.mk | ||
| CppunitTest_svx_dialogs_test.mk | ||
| CppunitTest_svx_gallery_test.mk | ||
| CppunitTest_svx_removewhichrange.mk | ||
| CppunitTest_svx_styles.mk | ||
| CppunitTest_svx_unit.mk | ||
| Executable_gengal.mk | ||
| IwyuFilter_svx.yaml | ||
| JunitTest_svx_unoapi.mk | ||
| Library_svx.mk | ||
| Library_svxcore.mk | ||
| Library_textconversiondlgs.mk | ||
| Makefile | ||
| Module_svx.mk | ||
| Package_gengal.mk | ||
| README.md | ||
| UIConfig_svx.mk | ||
| UITest_svx_table.mk | ||
Graphics Related Helper Code
Contains graphics related helper code. Lots of the draw and impress code is in this shared library.
-
xoutdevthis is where a lot of wht work would happen to move to the canvas. (what does that mean?)
-
svdrawtransparent gradient stuff. [seriously? surely much more, too]
SdrObject
The shapes you can see in LibreOffice (like rectangle, etc.) are SdrObjects. They are declared as a hierarchy:
SdrObject <- SdrAttrObj <- E3dObject <- E3dCompoundObject <- E3dCubeObj
^ ^ ^ ^ ^ | | ^ ^
| | | | | | | | +--- E3dExtrudeObj
| | | | | | | +----- E3dLatheObj
| | | | | | +------- E3dPolygonObj
| | | | | +--------- E3dSphereObj
| | | | +--- E3dScene...
| | | |
| | | +--- SdrTextObj <- SdrObjCustomShape...
| | | ^ ^ ^ ^ ^
| | | | | | | +--- SdrEdgeObj...
| | | | | | +----- SdrMeasureObj...
| | | | | +------- SdrPathObj...
| | | | +--------- SdrRectObj...
| | | +----------- SdrTableObj...
| | +--- SdrObjGroup...
| + ---- SdrPageObj...
+------- SdrVirtObj...
The above is incomplete of course.
SdrModel / SdrView
Copied from svdview.hxx:
First of all the app creates a SdrModel.
Then it opens a Win and creates a SdrView.
ShowSdrPage() announces a page at SdrView.
It's possible to show SdrView in any Wins at once.
SdrView can show as many Wins as it wants at once. Pages are announced
or checked out with the help of ShowSdrPage()/HideSdrPage(). For every announced
page there is a SdrPageView instance in container aPages. If more than one page
is showed, you have to pay attention that the offset parameter of ShowSdrPage()
is conformed to the size of the page (to prevent overlapping of two pages).
SdrView itself is inherited from many objects in a chain of inheritance (all
that starts with SdrPaintView - that is itself inherited from few classes
too):
SdrPaintView <- SdrSnapView <- SdrMarkView <- SdrEditView <- SdrPolyEditView
^
+----------------------------------------------------------------+
|
SdrGlueEditView <- SdrObjEditView <- SdrExchangeView <- SdrDragView
^
+----------------------------------------------------------------+
|
SdrCreateView <- SdrView
From SdrView on, it is not flat, but a real hierarchy again.
Drawing Layer / SdrObject(s)
See drawinglayer/README.md for general information about drawinglayer.
Below is the class diagram that comes from https://web.archive.org/web/20160827020830if_/http://www.openoffice.org:80/marketing/ooocon2006/presentations/wednesday_g11.odp slide number 6.
.------- Model --------------. .------- View -----------------------------------------.
| SdrObject - ViewContact | 1..* | ViewObjectContact |
| getChild() |------| getPrimitiveList() -----> Object(s) ---> SdrView |
| getVOC() | | getRecPrimitiveList() Contact |
| getViewInd... | |________|_____________________________________________|
| ...ependentPrimitiveList() | |
|____________________________| generates
| ______
V / |
.----------------------. |
| basePrimitive | |
| getRange() |<---'
| getDecomposition() |
|______________________|
For SdrObjects, there are own DrawingLayer primitives in
svx/source/sdr/primitive2d
The ViewContact / ViewObject / ViewObjectContact are in svx/source/sdr/contact
Decomposes the SdrObjects, and does all sort of operations on them.
If the number of visualizable objects (e.g. SdrObjects) is X, and the number of
SdrViews is Y, then:
- there are
XViewContactinstances (1:1 relation with a visualizable object) - there are
YObjectContactinstances (1:1 relation with anSdrView) - there are
X*YViewObjectContactinstances (1:N relation to both visualizable objects andSdrViews)