Closed hmijail closed 4 years ago
This looks like ignorable whitespace used in a CharClass definition, which it does not support: the relevant grammar rules are tagged /*ws: explicit*/
. What you want is
Byte::= [#x00-#xFF]
Even then, the result ends up being [#x0000-#x00FF] instead of [#x00-#xFF], and overruns the box in the diagram.
Admittedly adding the leading zeroes is somewhat arbitrary, so I will remove them somtime soon. But I can't see where it overruns the box. The SVG is rendered OK on the latest of Firefox, Chrome, and Opera, and the PNG looks OK as well.
Could you please provide some more details of where and what you are observing?
Firefox 77.0b9, macOS 10.15.3
But that is as it appears in the "view diagram" tab. The downloadable diagrams do look OK.
Predending of leading zeroes has been removed in the source code, so these will vanish in the next release.
The generated SVG is always the same, it does not depend on the environment where it is rendered. But it may look slightly different on different browsers, even on the same OS, or on different versions of the same browser, because of differences in font handling.
Usually the differences would be a few pixels only, but in this case it looks like a font of a larger size has been picked. Compared to usual sizes, the screenshot shows the box scaled up to 220%, but the font scale is 250-260%.
However this seems to be a problem of this specific OS and browser combo. I do not own a Mac myself, but I have asked friends to check on several Macs and the effect did not reproduce anywhere. The closest was Firefox 76.0.1 on a 16" Macbook Pro running Mac OS 10.15.5, and it was fine there as well.
There is nothing for me to do here.
This doesn't get well parsed, IIUC:
Byte::= [ #x00 - #xFF ]
Should be a CharCode range. And each CharCode gets expanded to 4 digits.