Turn Radek's notes into README files.

Change-Id: I904142622ac37b394ddedf62bb7d9c099fc9cab4

7 files changed, 318 insertions, 1 deletions

diff --git a/avmedia/README b/avmedia/README
index ad8120b5611e..32155b2ac1cf 100644
--- a/avmedia/README
+++ b/avmedia/README
@@ -7,4 +7,19 @@ streaming has to be wrapped around it via temp files.
 Also provides (in source/framework/mediacontrol.cxx) an implementation
 of the graphical media playback control that appears in the toolbar /
 mediaobject bar when media is selected under the .uno:AVMediaToolBox
-item.
\ No newline at end of file
+item.
+
+== avmedia/gstreamer ==
+
+The avmedia component is implementation of manager service defined in
+offapi/com/sun/star/media/. Radek has added implementation based on
+gstreamer so that we can add audio and video files into impress
+presentation on Linux with gstreamer.
+
+The implementation is pretty straightforward, sometimes it has
+problems when gstreamer installation is incomplete.
+
+In the beginning the media files were not embedded, Thorsten added
+support for that later.
+
+FUTURE work: it might be worthwhile to revamp the avmedia UI
diff --git a/canvas/README b/canvas/README
index 0110f5adfd55..2fb141c48148 100644
--- a/canvas/README
+++ b/canvas/README
@@ -24,3 +24,23 @@ 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 work: 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.
diff --git a/cppcanvas/README b/cppcanvas/README
index 246cb2d62838..1e9083101434 100644
--- a/cppcanvas/README
+++ b/cppcanvas/README
@@ -1 +1,5 @@
 Helper C++ classes for [[canvas]], plus a GDIMetaFile-to-XCanvas converter.
+
+== EMF+ ==
+
+For cppcanvas/source/mtfrenderer, see the README in vcl (the EMF+ part).
diff --git a/oox/README b/oox/README
index 43b60bd924d2..a1972fa5eef6 100644
--- a/oox/README
+++ b/oox/README
@@ -2,3 +2,188 @@ Support for Office Open XML, the office XML-format designed by Microsoft.
 
 See also:
 [http://wiki.services.openoffice.org/wiki/OOX]
+
+== DrawingML Custom shapes and presets ==
+
+custom shapes are part of DrawingML and are different to binary ppt
+and VML in older formats, so we needed to add new code to work with
+these. the import happens in oox/source/drawingml, where they are
+imported as LO's enhanced custom shape's. see
+offapi/com/sun/star/drawing/CustomShape.idl and
+offapi/com/sun/star/drawing/EnhancedCustomShape*.idl
+
+the export is quite behind now, as it was done before we started work
+on fully supporting drawingml custom shapes. (see FUTURE WORK below)
+
+example of drawingml preset:
+
+         <a:prstGeom prst="star5">
+           <a:avLst/>
+         </a:prstGeom>
+
+example of drawingml custom shape (equal to star5 preset):
+
+   <avLst xmlns="http://schemas.openxmlformats.org/drawingml/2006/main">
+     <gd name="adj" fmla="val 19098" />
+     <gd name="hf" fmla="val 105146" />
+     <gd name="vf" fmla="val 110557" />
+   </avLst>
+   <gdLst xmlns="http://schemas.openxmlformats.org/drawingml/2006/main">
+     <gd name="a" fmla="pin 0 adj 50000" />
+     <gd name="swd2" fmla="*/ wd2 hf 100000" />
+     <gd name="shd2" fmla="*/ hd2 vf 100000" />
+     <gd name="svc" fmla="*/ vc  vf 100000" />
+     <gd name="dx1" fmla="cos swd2 1080000" />
+     <gd name="dx2" fmla="cos swd2 18360000" />
+     <gd name="dy1" fmla="sin shd2 1080000" />
+     <gd name="dy2" fmla="sin shd2 18360000" />
+     <gd name="x1" fmla="+- hc 0 dx1" />
+     <gd name="x2" fmla="+- hc 0 dx2" />
+     <gd name="x3" fmla="+- hc dx2 0" />
+     <gd name="x4" fmla="+- hc dx1 0" />
+     <gd name="y1" fmla="+- svc 0 dy1" />
+     <gd name="y2" fmla="+- svc 0 dy2" />
+     <gd name="iwd2" fmla="*/ swd2 a 50000" />
+     <gd name="ihd2" fmla="*/ shd2 a 50000" />
+     <gd name="sdx1" fmla="cos iwd2 20520000" />
+     <gd name="sdx2" fmla="cos iwd2 3240000" />
+     <gd name="sdy1" fmla="sin ihd2 3240000" />
+     <gd name="sdy2" fmla="sin ihd2 20520000" />
+     <gd name="sx1" fmla="+- hc 0 sdx1" />
+     <gd name="sx2" fmla="+- hc 0 sdx2" />
+     <gd name="sx3" fmla="+- hc sdx2 0" />
+     <gd name="sx4" fmla="+- hc sdx1 0" />
+     <gd name="sy1" fmla="+- svc 0 sdy1" />
+     <gd name="sy2" fmla="+- svc 0 sdy2" />
+     <gd name="sy3" fmla="+- svc ihd2 0" />
+     <gd name="yAdj" fmla="+- svc 0 ihd2" />
+   </gdLst>
+   <ahLst xmlns="http://schemas.openxmlformats.org/drawingml/2006/main">
+     <ahXY gdRefY="adj" minY="0" maxY="50000">
+       <pos x="hc" y="yAdj" />
+     </ahXY>
+   </ahLst>
+   <cxnLst xmlns="http://schemas.openxmlformats.org/drawingml/2006/main">
+     <cxn ang="3cd4">
+       <pos x="hc" y="t" />
+     </cxn>
+     <cxn ang="cd2">
+       <pos x="x1" y="y1" />
+     </cxn>
+     <cxn ang="cd4">
+       <pos x="x2" y="y2" />
+     </cxn>
+     <cxn ang="cd4">
+       <pos x="x3" y="y2" />
+     </cxn>
+     <cxn ang="0">
+       <pos x="x4" y="y1" />
+     </cxn>
+   </cxnLst>
+   <rect l="sx1" t="sy1" r="sx4" b="sy3" xmlns="http://schemas.openxmlformats.org/drawingml/2006/main" />
+   <pathLst xmlns="http://schemas.openxmlformats.org/drawingml/2006/main">
+     <path>
+       <moveTo>
+         <pt x="x1" y="y1" />
+       </moveTo>
+       <lnTo>
+         <pt x="sx2" y="sy1" />
+       </lnTo>
+       <lnTo>
+         <pt x="hc" y="t" />
+       </lnTo>
+       <lnTo>
+         <pt x="sx3" y="sy1" />
+       </lnTo>
+       <lnTo>
+         <pt x="x4" y="y1" />
+       </lnTo>
+       <lnTo>
+         <pt x="sx4" y="sy2" />
+       </lnTo>
+       <lnTo>
+         <pt x="x3" y="y2" />
+       </lnTo>
+       <lnTo>
+         <pt x="hc" y="sy3" />
+       </lnTo>
+       <lnTo>
+         <pt x="x2" y="y2" />
+       </lnTo>
+       <lnTo>
+         <pt x="sx1" y="sy2" />
+       </lnTo>
+       <close />
+     </path>
+   </pathLst>
+
+we needed to extend our custom shapes for missing features and so 5
+new segment commands were added. G command for arcto drawingml record
+and H I J K commands for darken, darkenless, lighten, lightenless
+records. the commands are save into ODF in special namespace drawooo,
+which is extension not yet in the standard. Thorsten suggested to put
+it in such a namespace and keep original (incomplete) geometry for
+backward compatibility, before we can extend the ODF. that's why you
+will see 2 of them in cases where some of the new commands was
+needed. Radek backported code for the new commands to 3-6
+and 4-0 branches.
+
+the drawingml also contains new presets (compared to binary/VML) and
+so we now have code with these presets - they are basicallly
+predefined custom shapes. we generate them using scripts in
+oox/source/drawingml/customshapes/ and the output are
+oox/source/drawingml/customshapepresets[123456].cxx source files
+containing the definition for the preset shapes. this mean that we
+import presets from OOXML files perfectly. one area to look at might
+be check how handles on the imported custom shapes (and presets)
+wotk.
+
+the source code generation happens in these steps:
+
+  * generate pptx files by running generatePresetsPPTXs.pl. it
+    generates files in pptx/ from cshape.pptx sample - replacing
+    slide1.xml in it and placing it in new file in pptx/ named after
+    the preset plus one cshape-all.pptx file all the presets
+
+  * build oox module with debug (ie. make -s debug=t dbglevel=2)
+
+  * import cshape-all.pptx into impress and redirect output to
+    custom-shapes.log
+
+  * generate cxx files by running generatePresetsCXX.pl - it uses
+    debug output from the custom-shapes.log file and prepares the C++
+    source code
+
+  * check generated source code files customshapepresets[123456].cxx
+    and move them to oox/source/drawingml/
+
+  * build oox with new source files and test
+
+while importing presets, we also set the name of the custom shape so
+that we can detect it on export as save it again as preset.
+
+the scripts in oox/source/drawingml/customshapes/ also generate pptx
+files for signle presets and also for all presets
+cshape-all.pptx. the cshape-all.pptx file is then loaded into impress
+build with debug enabled in oox and the command line output contains
+information, which are used by generatePresetsCXX.pl. redirect the
+output into custom-shapes.log in oox/source/drawingml/customshapes/
+and run the script. it creates the customshapepresets[123456].cxx
+source files with presets definitions. also the generated pptx files
+can be used when debugging bugs in custom shapes import/export. also
+the cshape-all.pptx can be used to test the round trips. there's small
+problem with these pptx as they cannot be imported into powerpoint,
+but that can be fixed quickly. when fixed, we can use it to
+test powerpoint odp export and see how complete it is regarding
+custom shapes. OpenXML SDK tools might help when fixing
+cshape-all.pptx
+http://www.microsoft.com/en-us/download/details.aspx?id=30425
+
+FUTURE WORK: because we have to make sure that all the roundtrips
+like PPTX --> ODP --> PPTX work correctly and doesn't loose data.
+the only problematic part is probably saving custom shapes (ie. not
+presets) to PPTX. that part of code predates work on custom shapes
+and is unable to export general custom shapes yet. it will need a bit
+of work as LO has more complex equations than DrawingML. other parts
+should work OK, PPTX --> ODP should work and don't loose any
+data. presets should already survive PPTX --> ODP --> PPTX roundtrip
diff --git a/sd/README b/sd/README
index a64dbd4f9440..b8c236d13416 100644
--- a/sd/README
+++ b/sd/README
@@ -22,3 +22,22 @@ pptx. their locations are listed bellow:
    oox/source/drawingml and oox/source/*)
  * pptx export is in sd/source/filter/eppt (mostly in pptx-* source
    files) and shared part is in oox/source/export
+
+== PPTX export/import filters ==
+
+PPTX export filter is split into 2 parts. Impress related part is in
+sd/source/filter/eppt/pptx-* and the other part is in
+oox/source/export/ because it contains mostly code related to
+DrawingML, which is shared with writer and calc ooxml export.
+
+The export filter was written in 2009 IIRC and was not much extended
+feature-wise lately.
+
+FUTURE work: add custom shapes export (see below). enhance text
+output, we don't write text style for indentation levels now, need to
+export a:lvl1pPr, a:lvl2pPr, ... elements.
+
+PPTX import was written by Sun/Oracle and then extended in LibreOffice
+a lot during bug fixing. It is located in oox/source/ppt and
+oox/source/drawingml. The areas with most bugs (at least until today)
+were shape placeholders and text style inheritance.
diff --git a/slideshow/README b/slideshow/README
index f6d19bb53740..e523458531ae 100644
--- a/slideshow/README
+++ b/slideshow/README
@@ -1 +1,10 @@
 The Impress slideshow engine
+
+== 3D transitions ==
+
+The 3D transitions are slideshow transition engine using OpenGL and
+are located in slideshow/source/engine/OGLTrans/. They were initially
+written by GSOC student Shane.M.Mathews. Radek has later polished the
+code a bit, added few new 3D transitions, added infrastructure for
+vertex and fragment shaders. Wrote few transitions with fragment shader
+too.
diff --git a/vcl/README b/vcl/README
index 6fcf8607233d..e386843b076b 100644
--- a/vcl/README
+++ b/vcl/README
@@ -63,3 +63,68 @@ Note: references to "SV" in the code mean StarView, which was a
 portable C++ class library for GUIs, with very old roots, that was
 developed by StarDivision. Nowadays it is not used by anything except
 LibreOffice (and OpenOffice).
+
+== EMF+ ==
+
+emf+ is vector file format used by MSO and is successor of wmf and
+emf formats. see
+http://msdn.microsoft.com/en-us/library/cc230724.aspx for
+documentation. note that we didn't have this documentation from
+start, so part of the code predates to the time when we had guessed
+some parts and can be enhanced today. there also still many thing not
+complete
+
+emf+ is handled a bit differently compared to original emf/wmf files,
+because GDIMetafile is missing features we need (mostly related to
+transparency, argb colors, etc.)
+
+emf/wmf is translated to GDIMetafile in import filter
+vcl/source/filter/wmf and so special handling ends here
+
+emf+ is encapsulated into GDIMetafile inside comment records and
+parsed/rendered later, when it reaches cppcanvas. it is parsed and
+rendered in cppcanvas/source/mtfrenderer. also note that there are
+emf+-only and emf+-dual files. dual files contains both types of
+records (emf and emf+) for rendering the images. these can used also
+in applications which don't know emf+. in that case we must ignore
+emf records and use emf+ for rendering. for more details see
+documentation
+
+parsing:
+
+ wmf/emf filter --> GDI metafile with emf+ in commments --> cppcanvas metafile renderer
+
+lately the GDIMetafile rendering path changed which also influenced
+emf+ rendering. now many things happen in drawing layer, where
+GDIMetafile is translated into drawing layer primitives. for
+metafiles with emf+ we let the mtfrenderer render them into bitmap
+(with transparency) and use this bitmap in drawinlayer. cleaner
+solution for current state would be to extend the drawing layer for
+missing features and move parsing into drawing layer (might be quite
+a lot of work). intemediary enhancement would be to know better the
+needed size/resolution of the bitmap, before we render emf+ into
+bitmap in drawing layer. Thorsten is working on the same problem with
+svg rendering, so hopefully his approach could be extended for emf+ as
+well. the places in drawing layer where we use canvas mtfrenderer to
+render into bitmaps can be found when you grep for GetUseCanvas. also
+look at vcl/source/gdi/gdimetafile.cxx where you can look for
+UseCanvas again. moving the parsing into drawinglayer might also have
+nice side effect for emf+-dual metafiles. in case the emf+ records
+are broken, it would be easier to use the duplicit emf
+rendering. fortunatelly we didn't run into such a broken emf+ file
+yet. but there were already few cases where we first though that the
+problem might be because of broken emf+ part. so far it always turned
+out to be another problem.
+
+rendering:
+
+ before
+
+ vcl --> cppcanvas metafile renderer --> vcl
+
+ now
+
+ drawing layer --> vcl --> cppcanvas metafile renderer --> vcl --> drawing layer
+
+another interesting part is actual rendering into canvas bitmap and
+using that bitmap later in code using vcl API.