ODF 1.0 feature hyphenation-keep, i.e. disabling hyphenation across page etc. was implemented by shifting the full hyphenated line (fixing also the DOCX layout interoperability, when value of the useWord2013TrackBottomHyphenation MSO DOCX compatibility option is true). To shift only the last word, add UNO paragraph property com::sun::star::text::ParagraphHyphenationKeepLine and the associated layout in Writer core, i.e. disabling the hyphenation in the last line, instead of line shifting, if the value of ParagraphHyphenationKeepLine is true. Fix missing DOCX layout interoperability by mapping the unhandled useWord2013TrackBottomHyphenation = false case to the new layout. Note: shifting lines may be better for languages with long words, but only with 1) typesetting with line-level (greedy) line breaking instead of the desirable paragraph-level, 2) and with missing optimized hyphenation at boundaries of compound word constituents, and 3) forgotting the following: Shifting only words or word constituents are better for 1) equal line count on pages and spreads (very basic typographical requirement), 2) disabling hyphenation really (shifting doesn't guarantee this, because shifting is limited in a single line, but the previous line can be hyphenated, too) and 3) more compact typesetting. Both hyphenation-keep algorithms are important for interoperability, but the new HyphenationKeepLine can create state-of-the-art automatic typesetting with the planned improvements. Follow-up to commit9574a62add"tdf#132599 cui offapi sw xmloff: implement hyphenate-keep". and commitc8ee0e8f58"tdf160518 DOCX: import hyphenation-keep to fix layout". Change-Id: Iafa352ec91bbd5d1d227b8480337fa2b9acb5993 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181954 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: Jenkins
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 the 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)