CZ Report to CEN enquiry
- There are attributes named “maxFontHeight”, “maxFontSpacing”, “maxFontWidth”, “maxNumberOfCharacters”, “minFontHeight”, “minFontSpacing” and “minFontWidth”. These attributes are part of class VmsTextDisplayCharacteristics”. While these attributes could hold interesting information, it is usable only in case of non-proportional fonts. But there is no information about proportionality of font, which could be also interesting.
Proposed Solution by CZ
Add attribute “proportionalFont”, type Boolean. If true, then VMS can use (only or also) proportional font(s). If VMS can use only proportional fonts, then there will be no attributes like “maxNumberOfCharacters” etc. If VMS can use both types of fonts, then attributes like maxNumberOfCharacters” etc. may be present, but related only for non-proportional fonts.
this solution may be implemented defining this attriobute specifyng the use of a proportional font within VmsTextDisplayCharacteristics Class in VMSTablePublication or VmsDynamicCharacteristics Class in VMSPublication
This has to be better understood and analysed
In any case any update on this would result in UML model updates, so this would break the assumption that CEN documents complies to version 2.0.
Have to be solved in version 3.0
proportionalFonts Boolean attribute added in revision 809
In short: This CZ request can be ignored as it does not serve the purpose to inform about content on VMS.
The comment originates from my former colleague, who is expert on VMS design and he noticed the technical flaw, that proportional fonts and max number of characters do not match together much.
Few years later I see the issue differently. As we desperately need to simplify the model where efficient, we shall focus on purpose of each publication. In case of VMS the purpose is to convey information about published VMS content to another TMC, where it is enough to understand, what logical information is expressed and details about text sizing is not really important.
VMS publication is not intended for controlling the VMS devices.
The only other use case is to use DATEX II VMS publication as means for keeping inventory of VMS devices. As I am not aware of such use, I would consider this use case out of scope.
Proposed options are:
- simply ignore the original issue and mark it as rejected or as bogus.
- go even further and simplify the model by removing other details, which are not really necessary for understanding the content being shown on VMS. One possible case are details about used fonts.
- I would like not to introduce new classes, even if we have to describe Display characteristics, having all relevant font attributes merged (proportional characteristics can serve the fixed font also). But this is more implementation detail which I will happily leave to modelers.
I have discussed described approach with Petr Bureš and we agreed on it.
the aim of VMS publication is to exchange which information is displayed on VMS.
we can simplify the idea modeling Semanthic information but also the visual information can be assessed so more precise rendering of characters and exact image pictogram could be relevant for evaluating the performance of messages and VMS technology.
so the aim evaluating the original issue will be to improve our modeling to better describe information displayed on VMS.
at the end improved definition seeems needed or update modeling according to better proportional font characteristics description.