Status report: consultancy team, week 16, 2024

Status reports
1

Caolan

Mike

** SVG rendering issues in Writer
*** Looks like the problem is in VclProcessor2D::RenderTextSimpleOrDecoratedPortionPrimitive2D (drawinglayer/source/processor2d/vclprocessor2d.cxx)
*** It gets a font with an integer size: primitive2d::getVclFontFromFontAttribute
*** Likely we need then to apply additional MapMode to the output device, to fix the difference between the font height/width and aFontScaling/aFontSize.getX/Y
*** The exact position of the next character node is determined in SvgCharacterNode::createSimpleTextPrimitive (svgio/source/svgreader/svgcharacternode.cxx)
*** Both use TextLayouterDevice, which can make use of fFontScale* arguments passed to its setFontAttribute, to make up the error in all its getters
*** But that doesn’t work, the actual text width in RenderTextSimpleOrDecoratedPortionPrimitive2D is larger than what would be calculated in createSimpleTextPrimitive :frowning:
*** The position of : was more to the right in 7.0 compared to 24.2 (even though the actual rendering of the Tititi text was identical).
*** Initial regression after 1fa731d03ba0f22cb9392a578124ea977eaab2e9 - core - Gitiles
*** Final regression after a42f5faac7c6d4590e632cf40e3ba9eb618e6f56 - core - Gitiles
*** Likely needs making DXArray use doubles
*** => needs all OutputDevice conversion utilities have double variants
*** It turns out, that font size calculations are highly imprecise for small font sizes => SvgCharacterNode::createSimpleTextPrimitive needs to multiply several times to get better result
*** 160702 – Wrong and unstable positioning of text parts in SVG
*** It turned out, that OutputDevice::GetTextBoundRect isn’t correct for text width, because e.g. a space gives an empty bound rectangle
*** So needs to return double from OutputDevice::GetTextArray, and double variants of GetTextWidth / getTextHeight

Tomaz

PDF Reader - Create comments / add notes – improve slide & draw commenting

  • Code reading around the annotations
  • The issue with PDF annotations is that they are quite advanced in
    terms of what they support
    • for example:
      • “inline” annotation displays the annotation text inline in the
        document in a text box
      • “polygon” annotation displays a the annotation as a polygon in
        the document
      • “polyline” as a polyline
      • “arrows” is similar to connectors or arrows
      • “stamps” are images
    • the annotations can also be freely resized and moved
    • this looks very similar to various SdrObject objects instead of
      current implementation as handles
      • we would need to manually implement all that
    • so because of this the idea is to refactor the annotations to be a
      special kind of SdrObject
    • with that we get many things for free - inline text editing and such
  • First task - move the “Annotation” object into svx and the list of
    objects from sd::Page to SdrPage
    • done that mostly - after refactoring and moving the annotations
      still work as previously
  • Created an AnnotationObject - derives from SdrRectObj but could be
    changed to something different in the future
    • create and insert the object instead of the special SdrHdl (handle)
      object (and AnnotationTag deriving from SmartTags)
    • first need to support the “comment” annotation functionality
      available for comments in Draw/Impress - keeping the same look and feel
      of as before
    • WIP…

Miklos

Worked on: