157b027c4c
The fix tries to make rendering similar to MS Office. The ODF standard follows closely the extrusion in RTF and MS binary format. Rendering uses the 3D scene engine. The main problem was, that the z-component of the direction was interpreted with opposite sign. As result the maximum of a light was at false position. Especially a direction from the observer to the object has produced a light behind the shape and so looks as if light was off. The wrong z-direction has produced lighting, which was less intensive than in MS Office. To compensate that, a third light source was added as workaround. That part is removed. Second problem was wrong use of 3D-scene D3DMaterialSpecularIntensity and D3DMaterialSpecular (= UI Specular color). That was not only wrong in OOo but in my previous patch too. D3DMaterialSpecularIntensity corresponds to MS property 'c3DShininess'. Relationship is Intensity = 2^c3DShininess. D3DMaterialSpecular is calculated from MS property c3DSpecularAmt and and c3DKeyIntensity. The light source was missing, but needs to be included, because c3DSpecularAmt is 'the ratio of incident to specular light that is reflected on a shape'. The old unit tests are adapted to this change. MS gives no information how it softens a light in case of harsh=false. ODF specifies it as 'implementation-defined'. The patch uses four additional lights, which have directions in 60° angle to the original light. The light intensity is distributed. That comes near to rendering in MS Office. Changing our 3D engine to provide 'soft' lights was not doable for me. The way MS Office renders a 'metal' surface is different from ODF specification. To distinguish the kinds, I have introduced a new property MetalType. I have discussed it with the ODF TC (see minutes from 2022-02-07) and got the advise to use namespaced values. Therefore the datatype is not boolean. The 'Surface' drop-down in the extrusion bar is changed to make the two kinds of rendering 'Metal' available to the user. If a user sets surface 'Metal' in the UI of MS Office, it sets not only fc3DMetallic but reduces the value of c3DDiffuseAmt in addition. Our 3D-scene engine has the corresponding ODF attribute dr3d:diffuse-color not implemented. To get a similar rendering I change the material color of the 3D-objects as workaround. Change-Id: Ia986b9c318b4c79688e0c0e2d858215b9d612fdc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128449 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
LibreOffice Filters
Filter registration and some simple filters (also descriptions).
Desperate splitting of code into small shared libraries for historical
reasons presumably (OS/2 and Windows 3.x). The libraries produced from
the code in each subdirectory of filter/source/graphicfilter are
graphic format import or export filters. But they don't have uniform
API. Some have either a GraphicImport or GraphicExport entry point,
and are loaded and used in a uniform fashion from code in
svtools/source/filter/filter.cxx. Others have different API and are
loaded from other places. For instance icgm has ImportCGM, and is
loaded and used by sd/source/filter/cgm/sdcgmfilter.cxx (!).
Svgreader is used for "File -> Open" and then to choose the svg file.
For "Insert -> Picture -> From File", see svgio/source/svgreader directory.
Filter Configuration
The filter configuration consists of two parts, the type definition in
filter/source/config/fragments/types/ and the actual filter definition
in filter/source/config/fragments/filters/.
Each file type e.g. text file should be represented by exactly one type definition. This type can then be referenced by several different filters, e.g. calc text, writer text.