Addressing Label bounds and Fonts

[dgagne]

This issue is meant as a place holder for discussions regarding Labels.
It is a follow up to issue #330 and issue #458
In particular we are interested in label :

1. bounds definition and interchange
2. Font size to be expressed in Font Points or in Pixels
3. The effect these two have together on rendering
4. Text wrapping and within labels

[bzinchenko]

Traditionally, fonts are measured in points. This came from typography practice long before computers appeared. Publishers measure fonts in pt (point) and pc (pica). Printers have traditionally used these units in preference to cm or in.

This tradition was borrowed by desktop computers when they appeared. The most commonly used font system now is TrueType, which is a standard on Windows, Mac OS and even many Linux platforms under FreeType project. TrueType internally measures fonts in points.

Same applies to most desktop software, such as Microsoft Office, Open Office, Adobe Acrobat and nearly all other text editors and office packages around. Therefore, measuring fonts in points is de facto standard familiar to end users and desktop developers on all most popular platforms.

http://www.microsoft.com/en-us/Typography/default.aspx
http://www.adobe.com/products/type/opentype.html
http://freetype.org/index.html

[bzinchenko]

On another hand, WWW traditionally tends measuring fonts in pixels. CSS allow multiple font units, such as EM, PX, PT, CM, IN. However, there is explicit recommendation using pixels universally.
http://www.w3.org/Style/Examples/007/units.en.html

Therefore, a dilemma between points and pixels as font measurement units is a way existential dualism between desktop and web worlds. As such, it hardly has a single answer. We may allow both measurement units with explicit unit specification, as WWW did.

This situation already created a lot of confusion causing multiple internet resources offering conversion tools between points and pixels for web masters. I m not sure, if it is relevant to cite here these private resources. Everybody can google: "PT to PX" and see a long list of links.

[benmichel]

Thanks Boris, this is very enlightening!

In my opinion, the most problematic thing about the use of points as a unit, is that a label is surrounded by a box in pixels (the bounds of the label). Therefore every tool will have to convert the font size from point to pixel in order to determine the height and width for the label bounds.
I beleive that the use of point as the font unit contributes to complicate interchange since the conversion algorithm from point to pixel will surely not be the same from one tool to another.
My recommandation would be to do this the other way around : Store font size in pixels inside the bpmn, and leave it to editing tools to convert this to points if wanted (so font size would be displayed in points to the end user).

[bzinchenko]

In general, the formula to convert points to pixels and back is quite simple. There is no real magic behind. The only parameter, which defines transformation is so called "dots per inch" resolution of the target device. Screen rendering in all mainstream OS have well known predefined standard DPI not depending on the actual screen resolution, which they use. On Windows DPI defaults to 96, on Mac to 72. Knowing DPI, it is very easy to convert points to pixels. There are 72 points per inch, so we have:

points = pixels * 72 / DPI

[bzinchenko]

The real problem with points and pixels, as Benjamin correctly noted, is deducing required label boxes to hold the entire text universally between different tools. Every OS has its own functions to calculate the size of text box required to hold a given text. Underlying algorithm fundamentally relies on internal font metrics used by a particular OS. As discussed before, this is typically a calculation around dimensions of letters in TrueType font. Naively, these functions take font size in points to carry on calculations.

What really matters here, is rounding. Typically, you cannot have a fond size exactly matching some intermediary size with many significant digits. For instance, system will be hardly able to render precisely a font with point size of 12.3456789. Most probably, it will just round it to the closest integer value of 12 points. Same applies to font sizes in pixels. Especially with small fonts, these rounding discrepancies between font sizes in points and pixels may reach tens of percents. This will cause significant visual differences in font appearance due to rounding.

But rounding of font size as such is not the main problem here. Situation aggravates even more, if we consider label boxes. Label box is normally accommodated to hols words or even sentences. With dozens of letters on every line, a discrepancy for a single letter will be multiplied by a number of letters. Suppose we have label containing 20 letters. The actual discrepancy in calculation of proper box size for this label will be 20 times more than a discrepancy between points and pixels for a single letter.

These considerations make the goal of ensuring compatible label sizes almost not reachable in practice, although with sizes expressed in pixels the precision should be much better due to closer integration with internal OS rendering facilities.

[bzinchenko]

Luckily, BPMN specification for labels (section 12.3.1, page 411) does not require a label to have an obligatory label box. Taking numerous complexities with transformation of font sizes in a compatible manner, we should recommend to all tool vendors simply avoid using label boxes, unless they are absolutely necessary. In most cases, existing label boxes created by one tool should be just ignored during import into another tool to achieve the best compatibility. This recommendation concerns only width and height of a label box, not coordinates of its origin.

In practice, there is very simple and straightforward criteria to decide when a label box should be ignored or not. If a label contains just a single line of text, measuring and transferring its text box will create only an extra burden, which may lead to text aberration between tools, such as false multi-line text wrapping or accidental cutting of text by inappropriately narrow borders. In practice, single line labels account for a vast majority of practical cases.

If a label is contained inside of a surrounding shape, it is a good practice to confine its text box to this same shape. We should make shape borders also borders of a label box in this case.

Only in case of really large multi-line labels going far outside of their containing shapes should text box geometry be really considered and transformed during transfer of the diagram. But for such complex multi-line labels a possible misfit between tools should be less noticeable for a user.

Note: In general, filling a diagram with many complex labels of a novel's size is not a good modeling practice anyway. Therefore, for a typical professionally modeled diagram a transformation should succeed with minimal visually noticeable discrepancies by following above rules.

PS: Every standard should aim for a wide compatibility to be universally accepted. If a certain feature, such as a size of label box, causes numerous compatibility issues in practice, it is a good sign that this feature should be deeply revised or omitted at all.

[falko]

Would it be a solution to explicitly store the line breaks instead of the bounding box?

[bzinchenko]

Great idea! The standard tells nothing regarding storing line breaks. Therefore, they should be allowed as such.

Personally, I would vote for line breaks, although they wont resolve the problem entirely. For a complete solution line breaks should be accompanied with text justification settings. In this case we can rather speak about implied text boxes, which are calculated by every tool individually according to generic hints or clues supported by the format.

In any case, it is evident that exact text box size is not a transferable quantity in this specific context.

[benmichel]

Boris, You are right when you say that bounds are not mandatory for label, but when a label have bounds, all of it has to be taken in account. We should not start to choose what should be taken in account and what not.
If, as you say, the conversion algorithm between pixel and point is simple, then why not simply do as the specification says and store label size in pixels ? It then will be the job of the tool to show the font size in point to the end user if necessary (so the user can work with the current font unit). The diagram element bears a "resolution" attribute that could be use to do the conversion.
incidentally, as I reread the spec (part of it anyway), I came across this, on chapter B.4.3.1 about 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).

Also for the description of Font we have, on chapter B.3.3.3 :

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

This exactly addresses our issue here. The spec specify that the unit of length is pixel and specify a way to correctly print all the diagram (text included) by using the "resolution" attribute.

I would strongly suggest that we do as the spec says, since it it very clearly explain and does not leave room for interpretation. This will resolve our textboxt and line wrapping problem since all would be in pixel.

[benmichel]

I will make my case one last time about font size in pixels.

This unit we decide to choose for font size must chosen accordingly to the coherence of the whole picture. If we choose point, it should be because the use of pixel is incoherent, witch I beleive is not the case. The use of pixel is most relevant since it is the unit of length for all the spec, so it is very coherent to use it also for font size.

I understand that a lot of vendors serialize font in points and that the reference models are in points, so going back to pixels would require work. But that inconvienient amount of work shouldn't be the reason to choose points over pixels.

[bzinchenko]

Logically, using pixels is more evident and relevant. However, in terms of accuracy, we should follow to units used by most vendors. Transformation from points to pixels and back may cause discrepancies of several percents from original due to discrete scaling of pixels and points. For instance, declaring a font size of 8.5 pixels will make no sense. It will be anyway rounded to nearest integer size.

[SimonRinguette]

A doodle requesting vendor vote on the Points vs Pixel debate is available here: http://doodle.com/poll/fdm2m792kr2xx8sy

[bzinchenko]

According to comment by @nilei in issue #520, 'em' are preferred choice for font size in web development. 'em' is a unit, which directly translates to point size of font. If 'em' is a preferable compatibility choice for web development, hence, all units and especially fonts must be measured in points universally! It is an intrinsically evident choice because points are device independent and allow for the best compatibility across devices. So it is a situation I suspected intuitively but was not aware of.