User:Regina

Regina Henschel

Meine Tätigkeitsfelder:

Mitarbeit beim Draw-Handbuch (noch bei OOo unter SUN)
Mitarbeit an www.ooowiki.de
QA für neues Chartmodul, für neuen Druckdialog, für interne Matrixoperationen bei Draw-Elementen, für Report-Designer
QA im Issuetracker von OOo und Bugziller von LO
Anwenderbetreuung auf users-Mailinglisten
Core-Programmierung im Calc-Modul, insbesondere Verbesserung der Genauigkeit von statistischen Funktionen und Anpassen der Implementierung an ODF1.2 Normen.
Core-Programmierung im Chart-Modul, dabei Mitarbeit und QA für Größenänderung von Legenden und Anpassen der Spline-Implementierung an ODF1.2 Normen.
Bugfixes im Draw-Modul.
Mitglied im ODF TC, dem Normungsgremium für das Open Document Format

Drafts and Material for Discussions

User:Regina/DraftFacetsOfSettingsInToolOptions

User:Regina/HelpAuthoringDashboard

User:Regina/ODF_AngleProblems

User:Regina/ODF_3D_Problems

User:Regina/HowTo_Symbol_For_Character_Style

User:Regina/HowTo_Audiogramm_Koordinatensystem_de

User:Regina/Draw Examples

User:Regina/Compare SVG to Draw and ODF

User:Regina/Manipulate Markup of an ODF File

User:Regina/How to Make a 3D-star

User:Regina/How to make a color wheel

User:Regina/Custom Shape Tutorial

User:Regina/How to use SORT SORTBY FILTER functions

User:Regina/Macros for layers in Impress

User:Regina/Compatibility of Gradients

User:Regina/3D_From_File_Format_To_Rendering

User:Regina/Sandbox_for_additions_to_existing_pages

Für mich wichtige Links

Documentation/Bezierkurven/de
Development/ODF_Implementer_Notes/List_of_LibreOffice_ODF_implementation-defined_items
Development/ODF_Implementer_Notes/List_of_LibreOffice_ODF_Extensions
Documentation/DocumentationTeamInfo/StyleGuide
Development/Custom_Shape_Orientation_Guide
Development/Improve_handles_of_DrawingML_shapes
Development/Budget2024
CalcTableRef
Documentation/Calc Functions/XLOOKUP

Sandbox

[[1]]

Test Wiki-markup here

[math]\displaystyle{ \scriptstyle \sqrt {n+1} }[/math] <math>\scriptstyle \sqrt {n+1}</math>

[math]\displaystyle{ \sqrt {n+1} }[/math] <math>\sqrt {n+1}</math>

[math]\displaystyle{ s_{X_1 + X_2} }[/math] <math> s_{X_1 + X_2}</math>

[math]\displaystyle{ 1-P( -|z| \le Z \le |z|) }[/math] <math>1-P( -|z| \le Z \le |z|)</math>

[math]\displaystyle{ \textstyle \sum_{c=1}^N c^2 }[/math] <math>\textstyle \sum_{c=1}^N c^2</math>

[math]\displaystyle{ \sum_{c=1}^N c^2 }[/math] <math>\sum_{c=1}^N c^2</math>

[math]\displaystyle{ \int_{2}^{3}\frac{e^3/x}{x^2}\, dx }[/math] <math>\int_{2}^{3}\frac{e^3/x}{x^2}\, dx</math>

[math]\displaystyle{ slope \cdot (input-128)+128 }[/math] <math>slope \cdot (input-128)+128</math>

[math]\displaystyle{ a+2=b }[/math]

Achievement Hackfest Draft

I have worked on the topic "Make drawing layers ODF conform", mentored by Armin Le Grand. Find a detailed report on

Report about Hackfest topic "Make drawing layers ODF conform"

Drawing layers have a lot of problems. In regard to ODF these are

LibreOffice does not use <draw:layer-set> element in elements <draw:page> and <style:master-page> tdf#101218
LibreOffice does not use attributes draw:protected and draw:display of element <draw:layer> tdf#101242

Sketch out of an End Scenario

1. Each page may have an own layer-set in file format. That will be possible in LibreOffice too.

2. Each master page may have an own layer-set in file format. That will be possible in LibreOffice too.

3. The layer-set of the master page is used together with the layer set, which is defined on a page. In the UI it is possible to offer them side by side, or hide one.
ToDo: Define details. The specification has nothing about this case.

4. According ODF specification the default layer-set is only used, in case there exists neither a layer-set of the page itself nor of its master-page. This is the default situation in LibreOffice and will be kept.

5. The <draw:layer> element in file format contains the information about visible/printable/protected of the layer. In running program a view will have a local (only for this view valid) set of visible/printable/protected of the layers. The information about visible/printed/protected is hold in the view, so that different views can have different settings of visible/printed/protected. On saving the information from the active view is written to file. That is a current feature and will be kept. But the information is no longer written to settings.xml but transformed to attributes of the saved layer.

6. Objects refer its layer by name in ODF file format. Current LibreOffice uses internally a numeric ID of the layer. That will be changed so that LibreOffice uses the layer name internally too.

7. Layers will be identified by an internal name instead of the current numeric ID. This name will be written as draw:name attribute of the layer to file. The name will be fix throughout lifetime of the layer and unique. The user can set a display name. It will be written to file in extended namespace. If the user does not define a name, the internal one will be used in the UI.

8. ToDo: Specify copy&paste behavior of objects in regard of layers. This affects copying to Gallery too, tdf#33170. Possible ways e.g.: If an entire page is copied, it is handled as a saved document, which means, that the page layer-set, the layer-set of the referred master page and the default layer-set is copied together with the page into the clipboard and can be pasted if the user wishes that. New layers might be added on pasting. If single objects are copied, they will keep their layer in case the same page is used.
ToDo: Ask UX for behavior for copy&paste to different page or document, or drag to Gallery.

9. The layer "Dimension lines" will be removed as default layer. It will be no longer automatically added to documents created by other applications and not generated for new own documents.
ToDo: Ask UX about this.

10. The layer "Dimension lines" has currently the special feature, that "Dimension line"-shapes are automatically added to this layer, even if this layer is not the active one. This feature will be removed.
ToDo: Ask UX about this.

11. The layer "Controls" will be removed as default layer. Is will be no longer automatically added to documents created by other applications and not generated for new own documents.
ToDo: Ask UX about this.

12. The current layer "Controls" has the special feature, that objects, which reside in this layer are automatically shown in front of objects from other layers and currently the user cannot change this. This feature will be removed.
ToDo: Ask UX about this.

13. Form-controls in life-mode (non-design mode) jump to front before all other objects because they are real windows. That cannot be changed. To mimic this life-mode behavior the current implementation adds the form-controls automatically to the "Controls"-layer and uses the above described special feature of the "Controls"-layer. The form-controls in design mode will be handled same as other objects in regard to z-order and layer. A newly created form-control will be in front of other existing objects, same as any other newly created object.
ToDo: Ask UX about this.

14. The tab-list of layers will be only shown, if more than one layer exists. That will be the normal UI for new documents in case UX agree to not automatically generate the layers "Dimension lines" and "Controls".

It seems, that the layer "Background" is not used at all. At least it is not available in the UI. Action item for Armin: Check this.

The layer "Background objects" has currently some special features. Action item for Armin: Is it possible to remove such special rules?

Note: If UX agrees to remove the special handling of "Dimension lines" and "Controls", a lot of special handling parts can be removed from the code.

Note: If UX agrees about removing the layer "Dimension lines" and "Controls" as default layer, there would be only one default layer.

Transition to End Scenatio

Remover internal use of the bitfield

Change the representation from visible/printable/protected from bitfeld to something (internal class will follow) that holds page name, layer-set of page, active layer remark, visible/printable/protected for each layer.

The old bitfield is created from the new structure, when writing the document (likely in xmloff). The old bitfeld is interpreted and converted to the new format on loading (also likely in xmloff). The SdrLayerID from the SdrLayer is removed.

All user (including XLayer implementation (API)) of SdrLayerIDSet and SdrLayerID are changed to new structure.

Remove old internal bitfield.

Test that documents are unchanged in file format.

Check in

Note: Till now, the document format and the UNO API has not changed, but only the core.

Read the new format

If the attributes draw:display or draw:protected exist in the <draw-layer> element, then read it.

Note: Make sure, that existing draw:display and draw:protected exclude affected settings.xml items.

Extend API to “Layer2” or better name, so that property “VisibleLayers” or similar (e.g. sUno_View_VisibleLayers) can still be read and written and new properties too. Hint: This effects aViewProps.

Testdocuments for all cases for import.

Check in

Note: Now Libreoffice is able to read documents, which are produced by foreign application which do not write a settings.xml, but use only ODF means.

Write the new format

Export is extended to write ODF conform.
ToDo: Investigate and decide, whether only for default layer-set or parallel for master-page and page layer-sets.

Parallel keep old settings.xml for older LO versions.

Deprecate relevant items of settings.xml.

Remove items from settings.xml

To be done when relevant

Note: Further steps cannot be detailed, because there are a lot of UX decisions pending. Step 1 can be done immediately, because it only affects code internals.