OASIS Open Document Format for Office Applications (OpenDocument) TC

Greetings! Our chat notes from the ODF Teleconference - 07 August 2017 *****Camilla - chat only morphed into Camilla anonymous morphed into Thorsten anonymous morphed into Jos van den Oever Jos van den Oever: Hello everyone, just joining chat to say, i'm a bit later due to taking a wrong train. I guess Patrick will join and start the meeting. If not, i'll be at my desk at 18:15. Jos van den Oever: yes, i'm here and very glad you're here because i'm still on a train Jos van den Oever: i can and will Patrick: jos can you change my status? Jos van den Oever: done! Patrick: thanks Patrick: thanks thomas: I am on the call. My phone mic appears to not be working. Patrick: Have quorum Patrick: https://issues.oasis-open.org/browse/OFFICE/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel Patrick: https://issues.oasis-open.org/browse/OFFICE-3742 Jos van den Oever: i'm here Jos van den Oever: Regina: applications sometimes write svg:stroke-linecap, but on reading svg:stroke-linecap is ignored by all applications Jos van den Oever: Regina: only gnumeric does not use draw:style, but that is a bug because it interprets it wrong. Jos van den Oever: Andreas: It seems you use an old version of gnumeric. Jos van den Oever: Andreas: Gnumeric 1.10.16 is ancient. Regina Henschel: No, the other way round. draw:style is not used, but all use svg:stroke-linecap Jos van den Oever: Camilla: do not remove the attribute, but deprecate it so documents with attribute as still valid ODF. Jos van den Oever: Regina: oh, i'm very sorry for writing it wrong. Jos van den Oever: Correction: applications sometimes write draw:style, but on reading draw:style is ignored by all applications Jos van den Oever: Regina: so we can extend the proposal to deprecate draw:style and draw:stroke-dash-names. Patrick: The values of the draw:dots1-length, draw:dots2-length and draw:distance attributes of the referenced <draw:stroke-dash> element refer to the dashes without cap. Patrick: 19.135 draw:dots1 The draw:dots1 attribute specifies the number of dashes for the first sequence in an alternating sequence of dots. Patrick: proposed: 19.135 draw:dots1 The draw:dots1 attribute specifies the number of dashes for the first sequence in an alternating sequence of dots. ... These dashes do not use svg:stroke-linecap. Jos van den Oever: Regina: we should say that svg:stroke-linecap always has preference of draw:style. Jos van den Oever: Jos: that is an elegant way of solving the ambiguity Jos van den Oever: Regina: what would be the appropriate wording for the standard? Jos van den Oever: Jos: The current wording in the proposal is fine: it takes hierarchy into account. Patrick: For a dashed line, the caps are applied to each dash. -> For a dashed line, caps are applied to each dash. Patrick: If the referenced <draw:stroke-dash> element has an attribute draw:style, this is ignored. -> If the referenced <draw:stroke-dash> element has an attribute draw:style, the draw:style attribute is ignored. Michael Stahl: "This attribute is only evaluated for an object, if neither the graphic style on the object nor any graphic style up in the parent-hierarchy of it" -> "This attribute is only evaluated for an object if neither the graphic style on the object nor any of its parent styles" Patrick: contains a svg:stroke-linecap attribute. -> contains an svg:stroke-linecap attribute. Jos van den Oever: Patrick: When we use the word 'object', I know what it means, but is it the right word here? Jos van den Oever: Michael: we usually use 'shape' Jos van den Oever: Camilla: A question regarding 'it' in Michael's text. What does that refer to? Jos van den Oever: <i did not get the rest of Camillas question> Camilla : my question does the last "it" refer to a style hierarchy or the hierarchy of the shape/object Jos van den Oever: Michael: we sometime use 'object' and 'drawing object' to refer to shapes Patrick: 16.40.9 --- render strokes of shapes. Michael Stahl: Regina said the "it" refers to the style hierarchy Jos van den Oever: Patrick: draw:stroke-dah uses 'renders strokes of shapes' so what if we said: Jos van den Oever: There is an interplay between object and style hierarchy and normally both are followed to find the value for an attribute Patrick: if neither the graphic style on the object nor any of its parent styles" - if the graphic style of the shape contains a svg:stroke-linecap attribute. Jos van den Oever: Patrick: inheritence is already defined: we do not need to mention the inheritance. Jos van den Oever: Camilla agrees Jos van den Oever: Michael agrees too that the mention of hierarchy can go. Jos van den Oever: "This attribute is only evaluated for an object, if its style does not contains a svg:stroke-linecap attribute." ? Jos van den Oever: s/contains/contain Michael Stahl: also lose the comma Patrick: "This attribute is only evaluated for an object, -> "This attribute is evaluated for a shape,... Patrick: contains -> contain Jos van den Oever: "This attribute is only evaluated for a shape if its style does not contain an svg:stroke-linecap attribute." ? Jos van den Oever: "This attribute is evaluated for a shape if its style does not contain an svg:stroke-linecap attribute." ? Jos van den Oever: Regina is fine with the new working from the meeting. Jos van den Oever: Patrick updates the text in jira. Jos van den Oever: No objections to the text, it has been approved Regina Henschel: https://issues.oasis-open.org/browse/OFFICE-3928 Jos van den Oever: Regina: in the summary panel there is an issue with a very long text. We should read it before the next meeting. Jos van den Oever: So it would be good that the agenda mentions to prepare this issue. Jos van den Oever: Meeting adjourned. Hope everyone is at the start of a great week! Patrick -- Patrick Durusau patrick@durusau.net Technical Advisory Board, OASIS (TAB) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau Attachment: signature.asc Description: OpenPGP digital signature

Hello all, Our chat notes from the ODF Teleconference - 14 August 2017. Halfway the meeting Jos took over chair from Patrck. ==== Patrick: quorum Patrick: https://issues.oasis-open.org/browse/OFFICE-3928 Patrick had a minor comment on this proposal, a copying error. Jos: How to handle chart rectangles for 3d charts? Camilla: how is backwards compatibility handled? Regina: LO writes svg:width and svg:height in plotarea for backwards compat. Camilla: should we not require the width and height on plot-area? Jos: specifying width and height of the plot-area allows playing with the margin Regina: LO only shows one method in the UI Regina: so the plot rectangle implies the plot-area size in LO Camilla: that should not prevent others from writing it If relation between plotarea width and height and graph rectangle is fixed, we should specify what the relationship is Patrick: if there is a single coordinate system in the coordinate-region and you do not support that, you are ok with just recording width and height in plot-area but the new proposal would make the position of the coordinate-region independent of the plot-area Regina: the proposal states that these values should be ignored if coordinate-region is supported Patrick: what is the fallback if you do not support coordinate-region? would recording width and height do any good? Regina: so you want width and height be calculated such that they are in agreement with coordinate-region? Patrick: is that possible? Jos: can we specify this calculation in the same way such that application are interoperable? Camilla: if there is such a calculation, why change the spec? Jos: so implicit in this proposal is that calculating the relationship is hard, and that positioning the coordinate-region precisely is more important Regina: If you have month on one axis and you change the label from full to one character, that will resize the coordinate-region currently with this specification, the labels can ge changed without changing coordinate-region this make it easier to align different charts Camilla: still, you could calculate the coordinate-region, so you could store all values Regina: it is convenient to have these values in macros Camilla: how do you mean? Camilla: ok it makes sense Regina: For applications that do not support this, nothing changes. Camilla: if an application does not support coordinate-region, how does the application know the sizeof the plotarea Regina: the size is calculated in the same way as now Camilla: I'm worried about applications that do not write plot-area width and height Camilla: the 'should' should be a 'must' Regina: a 'shall' Jos: the width and height of plot-area should be stored, but the coordinate-region information takes precedence if there is a conflict, when the application cannot manage to fit the plot in the size given by width and height of plotarea Jos: is the relationship hard? Regina: you need to get size and position of labels and consider the pie chart where wedge breaks out Regina: the calculation of the bounding rectangle of coordinate-region with labels is the hard part Jos: Since label size depends on font size and many other things, this calculation is hard Camilla: the dimension of the plot-area would be the bounding rectangle Jos: so is x and y in plot-area also implicit now? Jos: because labels can also be on top of coordinate-region Camilla: yes, the bounding rect is hard to calculate Jos: maybe there should be two modes? on where you fix the coordinate-region and one where you fix the plot-area? Jos because clipping and overlap are also important concerns Camilla: when would you want that? Jos: it must have seemed sensible at the time to have the plot-area specify the graph layout Camilla: having the coordinate-region at all triggers that you want the other mode Jos: indeed, it already says this: If an element <chart:coordinate-region> is present, the attributes svg:x, svg:y, svg:width and svg:height at the element <chartlot-area> shall be ignored. Camilla: with the addition that plot-area *ahall* be written for backwards compatibility, this is fine. Regina: <chart:coordinate-region> is for the underlying object, not the size of the 3d object Jos: if there are graphs where none of the walls are parallel to the document layer, what does that mean for the <chart:coordinate-region>? Regina: you can have a true 3d scene Regina: chart:three-dimensional is not specified in depth (true / false) Jos: with 'true 3d' you mean dr3d namespace things i guess Jos: those also can be applied to normal <draw:rect> etc, so there must be rule on how to deal with those Jos: svg:width on chart:floor and chart:wall are not of influence of on <chart:coordinate-region> but do affect plot-area Regina: <chart:chart> in the attached file (LO_3D_ColumnChart_12extended.fods) has 3d information in chartlot-area, but not on coordinate-region Regina: the attribute on coordinate-region are the sizes of the result of the projection Jos: the handles in LO show the bounding box around the project, that fits what Regina says Andreas: then how does that help with lining up? The handles are not where I expect them to be Jos: in the 3d case <chart:coordinate-region> is the bounding box of the axes, just like in the 2d case but in the 2d case the meaning is easier (everything is harder in 3d) The alternative would be that the front wall would correspond to <chart:coordinate-region> Regina: excel does not have the option of 3d projection Camilla we should specify how to handle the <chart:coordinate-region> in 3d Jos: should we lock the coordinate region to the front wall or to the bounding box? Regina: I will investigate before we discuss furthere Jos: If you have more questions about this spec please mail them before the next meeting? Regina: should I add the 'shall' statement? Camilla: yes With that, the meeting is suspended -- Jos van den Oever co-chair OpenDocument Format Technical Committee ..................................................................................... Ministry of the Interior and Kingdom Relations Center for Standards Logius Wilhelmina van Pruisenweg 52 2595 AN Den Haag Postbus 96810 2509 JE Den Haag ..................................................................................... M +31(0)6-54715404 jos.vanden.oever@logius.nl www.logius.nl www.oasis-open.org/committees/office/ .....................................................................................

Greetings! Our chat notes from the ODF Teleconference - 21 August 2017 Activity last week: https://issues.oasis-open.org/browse/OFFICE/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel Continue graphics issue discussion https://issues.oasis-open.org/browse/OFFICE-3928 chart position without axis labels - 3D charts - pos/size for plot area and coordinate-region https://issues.oasis-open.org/browse/OFFICE-3930 Broken sentence in 20.226 presentation:display-date-time https://issues.oasis-open.org/browse/OFFICE-3931 Problems in 20.226 presentation:display-date-time thomas: I am on the phone. Not sure if you could hear me. We have quorum <coordinate-region> and 3D charts Regina proposes additions: If the <chartlot-area> element contains a <chart:coordinate-region> element, only the reduced content as described in section 11.x is used and the position and size values of the <chart:coordinate-region> element are used instead of those from the <chartlot-area>. Michael Stahl: by the way, in the web-chat you can click "Settings" and "Hide Smiley Faces" to disable this annoyance 11:5 The plot area may be displayed as an 3D scene as specified in section 10.5.2. All 3D attributes that can be applied to the <dr3d:scene> element can be applied to the <chartlot-area> element. This includes the dr3d:transform attribute that specifies the rotation of the three-dimensional plot area. 10.5.2 The <chartlot-area> element may contain a <dr3d:light> element as specified in section 10.5.3. Michael: thanks Jos: does this mean that the labels become disconnected from the axis? Regina: no, it only is about the size and position attributes. a 3d scene is a like a picture and the size and position say how large the picture / projection is Regina: so the picture has to be scaled to the desired size. Regina: when you only have the plot-area, then the reference size includes the labels Regina: when you have a coordinate region, then the reference size excludes the labels Jos: I understand, it's the right approach Jos: I was referring to https://lists.oasis-open.org/archives/office/201708/msg00016.html We need a new issue for the second point in that mail about the sizes of 3d scenes. Regina will put this text in a new issue. Andreas: about the 3d scene Andreas: what does uniform scaling mean? Regina: you have content in 3d, you make a projection and obtain a 2d picture Regina: you have to bring this 2d projection to the canvas Jos: And that is where you need the scaling Andreas: I still do not understand the 'uniform' part Andreas: depending on the projection the scaling might not be uniform, esp to meet the width and height constraints Andreas: what is the intent of 'uniform' in that phrasing Andreas: take a rectangular box, that is rotated, now an object that needs to have a projection fit in a viewport Andreas: what is uniform in that scaling? Andreas: I understand as uniform as having the same scaling in all directions Regina: it has to be scaled such that it touches the edge of the viewport Regina: it does not need to fill out both width and height Andreas: so saying that it should 'fit the viewport' would suffice Andreas: why am I getting a wider viewport as needed Jos: The box is meant to constrain the place where the chart can go out Andreas: if we say shall instead of should we might break the normal behaviour Jos: Andreas, can you describe the current behaviour Andreas: if you widen the viewport, the projection will change Regina: you want that the producer write the tight box around the projection image? Andreas: that is how i would understand uniform scaling Regina: it might be that the actual rendering in an application does not fit Regina: I've to give a description that would allow the sizing/drawing/dimension in an application to vary but would constrain the aspect ratio and size of the coordinate-region of the chart Jos: perhaps we can say that the image should be fitted but without skewing or distorting the image Jos: SVG has https://www.w3.org/TR/SVG11/coords.html#PreserveAspectRatioAttribute this attribute for this situation Jos: The SVG specifcation also talks about 'uniform scaling' https://www.w3.org/TR/SVG11/images/coords/PreserveAspectRatio.png Jos: Exact text: "it is desirable that uniform scaling be used for the purposes of preserving the aspect ratio of the graphics." Jos: a possible improvement: "producers shall use uniform scaling to fit the *project of the scene* to the viewport." Thorsten: ain't the more precise word 'isotrophic scaling' here? Andreas: it does not matter where we put the adjustability, we should not say 'fitting to the viewport', if the width is smaller then is the image in the middle, the left or the right Andreas: we should explictly say that it should be centered Regina: it should be fitted centered into the viewport. 'into' rather than 'to' Andreas: The images showing the possible fittings as preserveAspectRatioAttribute handle all the possibilities Andreas: the current text seems to suggest xMinYMin sorry, error by jos: xMidyMid Jos: would it be reasonable to have any behavior other than xMidYMid? note: we mean 'meet' which is the default Jos: any rotation would reduce the size of the projection Andreas: that depends on the initial shape Jos: if you rotate exactly around an axis You create protrusions by rotation which have to go back into the box which means scaling down Jos: you'll never get a scaling larger than the 2d scaling Jos: Maybe the current behavior is to not scale at all Regina: in LibreOffice, the chart will scale up or down when you are rotating it Jos: for scene objects in LibreOffice the box expands and shrinks when rotating Regina: for charts this is different, this is required, because the periphery of the chart stays the same Regina: the draw:frame stays the same Jos: but for other scenes the draw:frame does change in size Regina: yes "Producers shall use uniform scaling to fit the image to the viewport. " "Producers shall use uniform scaling to center the maximum image into the viewport." "Producers shall use uniform scaling to center the maximum image inside the viewport. This part should only be for charts. Regina: yes. Andreas: the text should concern everything Andreas: The increase in size while manipulating the image is a UI behaviour. Andreas J Guelzow: bye We can take up the pos/size of the plot area next week. Meeting adjourned.