Re: Problems with data labels in charts
Hi Miklos, Miklos Vajna schrieb am 18-Aug-20 um 09:19: Given it's there since 2014, I think there is benefit in not breaking that. I would rather add the remaining missing LabelFoo properties and keep the existing API working than the other way around. Besides missing unit tests, import is finished now. Please have a look at https://gerrit.libreoffice.org/c/core/+/101194 and tell me, whether that's the way to go. Kind regards Regina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Problems with data labels in charts
Hi Miklos, hi all, Miklos Vajna schrieb am 18-Aug-20 um 09:19: Hi Regina, On Mon, Aug 17, 2020 at 08:19:37PM +0200, Regina Henschel wrote: So you suggest to keep the internal structure? That would mean, we will get about 18 additional "LabelFoo" properties over the time for the still missing fill and line properties. That is indeed some cost to be considered. Then these needs to be done: A) Implement import of such ODF files, which use the styles of elements for the fill and line properties of labels, so that this information goes into the internal "labelFoo" properties. B) Implement export to ODF, so that it writes the "labelFoo" properties into the styles of elements, initially in addition to the loext:labelFoo attributes. C) Implement a service for the "labelFoo" properties. (Currently they are not officially available in the API, although they are visible in the Basic IDE.) The problem was not introduced by Gülşah, but this structure was determined by Kohei Yoshida July 2014 with commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=f1531cdaaebe706d909dc6ddde439ccb5f4ad36d Ah, thanks for researching that, so it's older. Given it's there since 2014, I think there is benefit in not breaking that. I would rather add the remaining missing LabelFoo properties and keep the existing API working than the other way around. I have now started with A). It is in https://gerrit.libreoffice.org/c/core/+/101194. That makes it easier to speak about the problems. The current state is, that the styles, which are referenced by a element are read and that the attributes svg:x and svg:y for the absolute position are read. My ides is, to change the property names of the fill and line properties from their usual shape names to the "LabelFoo" names and then interpret the style as series or data point style respectively. Such changing is missing yet. Before I continue, I want to ask, what do you think about the idea? Or do you have a better idea? Not addressed is the position problem. Neither series nor data points have a property to hold an absolute position. And converting to the relative positions of Custom Position is only possible, if the data label position according the LabelPlacement values is known. But that is unknown, when styles are applied in SchXMLSeries2Context::setStylesToSeries or SchXMLSeries2Context::setStylesToDataPoints Custom Position was introduced by Balazs Varga with commits 4223ff2be69f03e571464b0b09ad0d278918631b and 2a00d51150d410110602c953b3c3895debfcaa98. If you have an idea for that, please tell me. Kind regards Regina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Problems with data labels in charts
Hi Regina, On Mon, Aug 17, 2020 at 08:19:37PM +0200, Regina Henschel wrote: > So you suggest to keep the internal structure? > > That would mean, we will get about 18 additional "LabelFoo" properties over > the time for the still missing fill and line properties. That is indeed some cost to be considered. > Then these needs to be done: > A) Implement import of such ODF files, which use the styles of > elements for the fill and line properties of labels, so > that this information goes into the internal "labelFoo" properties. > B) Implement export to ODF, so that it writes the "labelFoo" properties into > the styles of elements, initially in addition to the > loext:labelFoo attributes. > C) Implement a service for the "labelFoo" properties. (Currently they are > not officially available in the API, although they are visible in the Basic > IDE.) > > The problem was not introduced by Gülşah, but this structure was determined > by Kohei Yoshida July 2014 with commit > https://cgit.freedesktop.org/libreoffice/core/commit/?id=f1531cdaaebe706d909dc6ddde439ccb5f4ad36d Ah, thanks for researching that, so it's older. Given it's there since 2014, I think there is benefit in not breaking that. I would rather add the remaining missing LabelFoo properties and keep the existing API working than the other way around. Regards, Miklos ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Problems with data labels in charts
Hi Miklos, Miklos Vajna schrieb am 17-Aug-20 um 10:08: Hi Regina, On Sun, Aug 16, 2020 at 05:27:07PM +0200, Regina Henschel wrote: So there are discrepancies between what LibreOffice writes and reads and what exists in ODF. What to do? Regarding data label fill style, I think Gulsah added that recently in commit 603df08a1e0211099ce2cf258cfe64a74ed6ded9 (2020-05-04). So in case the used ODF markup is wrong, it is OK to just fix that without worrying about backwards compat. The use-case in that commit was OOXML import + correct rendering, so again, ODF markup can be tweaked. So you suggest to keep the internal structure? That would mean, we will get about 18 additional "LabelFoo" properties over the time for the still missing fill and line properties. Then these needs to be done: A) Implement import of such ODF files, which use the styles of elements for the fill and line properties of labels, so that this information goes into the internal "labelFoo" properties. B) Implement export to ODF, so that it writes the "labelFoo" properties into the styles of elements, initially in addition to the loext:labelFoo attributes. C) Implement a service for the "labelFoo" properties. (Currently they are not officially available in the API, although they are visible in the Basic IDE.) The problem was not introduced by Gülşah, but this structure was determined by Kohei Yoshida July 2014 with commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=f1531cdaaebe706d909dc6ddde439ccb5f4ad36d Kind regards Regina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Problems with data labels in charts
Hi Regina, On Sun, Aug 16, 2020 at 05:27:07PM +0200, Regina Henschel wrote: > So there are discrepancies between what LibreOffice writes and reads and > what exists in ODF. What to do? Regarding data label fill style, I think Gulsah added that recently in commit 603df08a1e0211099ce2cf258cfe64a74ed6ded9 (2020-05-04). So in case the used ODF markup is wrong, it is OK to just fix that without worrying about backwards compat. The use-case in that commit was OOXML import + correct rendering, so again, ODF markup can be tweaked. Regards, Miklos ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Problems with data labels in charts
Hi all, as far as I understand, we have currently this situation: Graphic properties -- A data label is created as css.drawing.TextShape and as such it can have FillProperties, LineProperties and ShadowProperties. In ODF, a data label is a element and its style can have graphic properties. The data labels in MS Office have graphic properties too. Our model has no explicit data labels, but all about data labels is contained as properties in a data point or as default in a data series. But data points and series have graphical properties themselves. So when graphic properties for data labels were introduced (such doesn't exist in OOo), new properties of kind "LabelFillColor" were created, see https://opengrok.libreoffice.org/xref/core/chart2/inc/unonames.hxx This graphic properties are written to ODF in loext namespace into the style of the data point or series instead of writing into the style of the element. That is wrong. If a data label gets graphic properties in MS Office and the file is written to ODF by MS Office, then the properties are correctly in the style of the element. But LibreOffice cannot interpret it. Position -- The user can drag a data label to a different position. This corresponds to "CustomLabelPosition". Latter is relative to the position calculated from the "LabelPlacement". (Do I understand this correctly?) ODF has for a user defined position the attributes svg:x and svg:y of the element. These describe the position relative to top/left of the entire chart. MS Office uses these attributes in its export to ODF. (OOXML has the element manualLayout, but I do not understand its unit.) LibreOffice allows the user to drag the data label, but does not write the new position into the ODF-file at all and therefore has it lost on reopening. So there are discrepancies between what LibreOffice writes and reads and what exists in ODF. What to do? Kind regards Regina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
