Hi Mark, Mark Hung schrieb:
Hi Regina, Sorry that being late to reply about this topic.
It is on the agenda of the TC, but we will surely not decide next Monday. I've spend some time in
oox last year. I try to make built-in shapes export to ooxml as much as possible.
The problem with built-in shapes in the view of ODF file format is, that the rendering in LO depends on 'draw:type' attribute. But that should not be.
It might be a little wired, but my major concern about
blending to another color value is how reset of the filters can emulate the effect. Currently users can group different shapes with different transparency. That might be an alternative although there are still differences.
I do not understand you. The problem is how to specify changes to the color of a subpath in an enhanced geometry.
The current implementation has three concepts:(1) Use the new commands H I J K inside the 'drawooo:enhanced-path' attribute in case of draw:type="ooxml-foo" and direct pptx import. (2a) Use a value for the member nColorData which is set from constants inside the ctor of the enhanced-geometry. This is used in case of "mso_sptfoo". (2b) Extract the value for the member nColorData from the value in draw:type. That is done for the cases draw:type="col-nnn". That is used for the shapes "Octagon Bevel" and "Diamond Bevel", but would work for other shapes too, see attached document.
The colors in (1) are currently different from the specification for the OOXML attribute 'ST_PathFillMode'. I think, that is a bug and have proposed a patch to change that.
But using nColorData allows colors, that cannot be represented with the four values possible in the OOXML attribute 'ST_PathFillMode'. On the other hand, besides the shapes "ActionButtonHome" and "CurvedArrow" only 20% and 40% is actually used and LibreOffice is not effected for direct pptx import but only for documents which already contain shapes of type "mso_sptfoo" or "col-nnn".
Kind regards Regina
Best Regards. 2017-01-14 23:34 GMT+08:00 Regina Henschel <rb.henschel@t-online.de <mailto:rb.henschel@t-online.de>>: Hi all, the ODF TC is going to discuss https://issues.oasis-open.org/browse/OFFICE-2049 <https://issues.oasis-open.org/browse/OFFICE-2049>. The MS Office preset shapes have subpaths, which are lighten or darken, e.g. the shape type “Borders”, which is “quad-bevel” in LibreOffice. The issue is about adding a way to store such subpath information in the file. In ODF 1.2 it is not possible. Apache OpenOffice does not store the information, but renders the shape depending on its type name. That works only for the preset shapes of OOXML. In LibreOffice this subpath information is stored as new path commands. LibreOffice uses an own namespace “drawooo” for that. This has been added by commits by Radek Doulik at 2012-01-11. But the implementation is faulty, see https://bugs.documentfoundation.org/show_bug.cgi?id=105266 <https://bugs.documentfoundation.org/show_bug.cgi?id=105266>. On the other hand there is the request for multiple colors for the enhanced-geometry, see https://bugs.documentfoundation.org/show_bug.cgi?id=103298 <https://bugs.documentfoundation.org/show_bug.cgi?id=103298> I can imagine this solution: Add a new attribute to the <draw:enhanced-geometry> element which carries a list of value pairs. Such pair has a factor from [0;1] for the degree of blending and a color value for the blending color. Such attribute would be able to carry the information needed for “lighten” and “darken”, but give the additional opportunity to implement color change in subpath. My question, should ODF 1.3 follow the current LO way and add new path commands? Or do you like my other idea, or do you have a different idea? Kind regards Regina _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org <mailto:LibreOffice@lists.freedesktop.org> https://lists.freedesktop.org/mailman/listinfo/libreoffice <https://lists.freedesktop.org/mailman/listinfo/libreoffice> -- Mark Hung
Attachment:
BlendingFromType.fodg
Description: application/vnd.oasis.opendocument.graphics-flat-xml