Reference C.1.0: Resolution attribute missing in DI

[krat0s]

The resolution attribute is missing in bpmndi:BPMNDiagram element.

The missing attribute will result in tools defaulting to their own value of choice (e.g. itp-commerce = 72, trisotech = 96). While this does not affect the overall look of the diagram (as all shapes are scaled proportionally), it does make a difference to the shape-size/font-size ratio, as the font size, as I understand, is measured in points and is not scaled with respect to the resolution.

The following two images show the different results.

Resolution = 72

Resolution = 96

In my opinion, the following line:

<bpmndi:BPMNDiagram id="sid-78cf0368-c97e-4dea-885f-0e535c20d6c7" name="Collaboration C.1.0">

should be changed to this:

<bpmndi:BPMNDiagram id="sid-78cf0368-c97e-4dea-885f-0e535c20d6c7" name="Collaboration C.1.0" resolution="96">

[benmichel]

In the spec we can read page 490, concerning 'Diagram' :

All lengths specified by diagram elements are expressed in logical units of lengths. This unit of length would map to a unit of screen resolution (i.e. pixel) when rendering to the screen. To allow for predictable lengths when printing diagrams to paper, a diagram can also specify an intended printing resolution in Unit Per Inch (UPI)

And page 485, concerning 'Font', we can read :

size : Real [0..1] a non-negative real number representing the size of the font (expressed in the used unit of length).

What I understand from that is that when displaying a diagram on screen the unit of length used in diagram must be the pixel and the unit for Font size is the used unit of length, so the pixel. I understand that the resolution attribute is to be used only when printing on paper to give a scale for the diagram.

My conclusion is that each tools should display labels the same way withtout depending on the diagram"resolution" attribute, but only depending on the font size with the pixel unit of length.

[krat0s]

Proceeding from the assumption that the font size is measured in pixels, then the issue is with the font size value.

Taking the task 'Archive original' as an example, we have the following shape data:

      <bpmndi:BPMNShape id="sid-CFAC8502-0E69-4F08-BE36-8499B8C0FA44_gui" bpmnElement="sid-CFAC8502-0E69-4F08-BE36-8499B8C0FA44">
        <omgdc:Bounds height="80.0" width="100.0" x="315.0" y="93.0"/>
        <bpmndi:BPMNLabel id="Bpmndi_BPMNLabel_rynbMJ2DEeSTzqyH1_lhMw" labelStyle="Bpmndi_BPMNLabelStyle_M44qwJ1_EeS1-pEyeWEPig">
          <omgdc:Bounds height="36.0" width="63.0" x="334.0" y="115.0"/>
        </bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>

As well as the following font data:

    <bpmndi:BPMNLabelStyle id="Bpmndi_BPMNLabelStyle_M44qwJ1_EeS1-pEyeWEPig">
      <omgdc:Font name="Segoe UI" size="9.0"/>
    </bpmndi:BPMNLabelStyle>

If the unit of length is the same for the shapes and the font, i.e. pixels, then the task shape is high enough to contain 8.88 lines of text (80/9 = 8.88).

The reference image, however, suggests that the text is much larger than that. In fact, it looks like the task shape can only hold about 5.5 lines of text.

In the itp-commerce Process Modeler import results, however, the shape easily fits 8 lines of text.

Here is a comparison of the reference image with the itp-commerce Process Modeler import results:

The label bounds are also larger than the text. In fact it is double the size. The height of 36 pixels gives room for 4 (=36/9) lines of text. Assuming that tool vendors will center their labels within the bounds-box, this may not be a problem. If they, however, align the text to the bounds then the label will be within the upper half of the bounds-box and hence shifted to the top half of the task shape.

[dgagne]

Webmeeting 18 Mar 2015
o Identified a bug in the C.1.0 reference model regarding the bound and also font values
o A new corrected version of C.1.0 Model and depiction will be submitted

[benmichel]

The fix has been done and the pull request has been created and is just awating acceptation.

[krat0s]

Based on last week's discussion and agreement that the font size is measured in pixels rather than points, I believe that most reference files will need to be revised.

Example: A.1.0
The task height is 68 pixels. The font size is 8 pixels.
When converted to inches with a resolution of 96 we obtain a task height of 0.70833 in (68/96) and a font size of 0.0833 in (8/96), which equals a font size of 6 points (0.0833*72).

In the reference Visio file, the height of a task is 0.7087 in while the font is 8 points. 8 points correspond to 0.1111 in, which is the equivalent of 10.6666 pixels using a resolution of 96 ppi.

The reference image does therefore not match the bpmn file. Either the font size of the bpmn file should be set to 10.6666 pixels or the images should be adapted to reflect the smaller font size of 6 points.

The same observation can be made for almost all other reference files.

[bzinchenko]

In my view, measuring fonts in pixels is practically impossible and professionally inappropriate. Historically, font sizes are always expressed in points, never in pixels. A fixed universal ratio between points and pixels simply does not exist because it depends on a rendering device context, DVI resolution, typesetting subsystem, OS and even on a programming language and a development framework.

Even if, by a miracle, it will be possible finding a visually appealing balance between these factors on a specific rendering context of a test diagram, it will be immediately broken by a simple change in zoom factor of a diagram, just because quantization step and granularity of a font measured native in points will never match precisely with varying pixel resolution, which has completely different stepping and incrementing rules.

[dgagne]

Webmeeting 8 Apr 2015
o It was decided that as per the spec, font size should be specified into pixels
o This will require all test cases and test results to be redone from all vendors

[dgagne]

Webmeeting 7 Oct 2015
o We decided to suspend the 8 Apr 2015 decision to move Font size to pixel for all reference test cases
o We decided to open an overall issue specific to Labels including Bounds and Fonts related considerations