[css-syntax][css-values] Add IEEE 754 float hex format SVG/CSS values

[SieuDoTia]

Please add IEEE 754 float hex format SVG/CSS values. Need hex format for create high precision line screen/half tone for print for use SVG replace PDF.

• Only need single precision float (32 bit float IEEE 754)
• use format "0x--------" from C, no confuse with "#---" or "#------" hex use for color
• format need 10 characters maximum, hex number shorter than decimal number for same precision, smaller file size
• big endian (more easy for human read it)
• also float format for color important for high precision/color control in print industry

Example SVG file here use big endian IEEE float format for draw grey circle with radius 100 at (50; 50), fill opacity 1.0 (color here):

Example SVG file here use big endian IEEE float hex format for draw grey (50%) circle with radius 100 at (50; 50), fill opacity 1.0:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg version="1.1"  width="100" height="100" >
  <circle cx="0x42480000" cy="0x42480000" r="0x42C80000" fill="rgb( 0x3F000000, 0x3F000000, 0x3F000000)" fill-opacity="0x3F800000" stroke="none" />
</svg>

[faceless2]

Not sure you'll get much agreement on this, but I would like to see your example SVG files if possible to better understand the problem. Github won't accept SVG as attachments in the comments, but you could upload them to https://gist.github.com/

[tabatkins]

(I editted the original comment to properly put the example in a code block; it was being interpreted as (invalid) markup and not being displayed.)

[tabatkins]

So it looks like you're just asking for a new way to write numbers, right? You want to write out numbers as the literal bit pattern of a 32-bit float.

I feel pretty confident that we'll reject this without a very good reason otherwise.

• All of the numbers in your example are much longer written that way than in the normal way as integers (where they need only 2-3 characters). I'd like to see examples of numbers which a) require more than 10 characters to write in standard decimal, and b) actually require the precision of those extra digits.
• Float bit patterns are unreadable by humans. I have to do some work to decipher 0x42480000 into 50⏨, and the only reason I can do so is because I'm weird and find the minutia of bit patterns interesting to remember.

You mention "high precision line screen/half tone for print for use SVG replace PDF" - what do you mean by this? Why do you need a 32-bit float syntax specifically to achieve this?

[AmeliaBR]

To keep the discussion in one place, here's my reply from when this request was originally posted to the www-svg mailing list.

Key points (beyond suggesting filing it here):

I can see a few obstacles:

• SVG currently only requires single-precision floats, not double. CSS doesn't currently specify precision requirements; there is an open issue suggesting that it should be formally made undefined behavior ([css-values-4] Explicitly undefine CSS numeric precision in general #4552).
• The #nnnnnnnn format is already used in CSS and SVG for colors. Parsing would be ambiguous in some CSS properties. [Edit: this issue is addressed by using an 0x syntax]
• CSS (and SVG) are mostly harmonizing with JavaScript (ECMAScript) for any new Math-related features, and JavaScript doesn't have any hex-based formats for floats. [Edit: the 0x syntax is a problem from this perspective, since in JavaScript it is always interpreted as an integer, not a float!]

You might get more support for a request to specify the parsing/rounding rules for converting between decimal representation and binary floats (which would most likely match the ECMAScript specification, and use the "round to nearest, with ties to even" rule). With this guaranteed, you could be confident that a decimal version of a number would always parse into the same binary representation. But first, the precision level (single or double float) would need to be defined.

[SieuDoTia]

Small line screen SVG image I create from PNG file. I assume one SVG unit is 1/96 inch (1/37.8 cm) this line screen is 192 lines/inch (75.6 lines/cm), high resolution line screen. Format for float decimal number have 5 digit after decimal point. I can't load this use https://gist.github.com/ because "add file" button not work. I put image in MediaFire:
https://www.mediafire.com/view/7pq3kekavb278ge/line-screen_192lpi.svg/file

[faceless2]

I've taken the liberty of putting your image at https://gist.github.com/faceless2/042847e3675648dfbe4fe5a81000de02 - unchanged, although I added the SVG namespace. Mediafire tried to give me some dubious binary as well as your file.

I see where you're going with this. Obviously the SVG is machine generated, it strikes me that scaling every dimension up by 1000 and set "viewBox="0 0 89000 95000" would avoid any issues you're having with float resolution.

If you're converting these to/from PDF, be aware that the maximum recommended resolution of numbers in PDF is roughly 5 decimal places in PDF 1.4, roughly IEEE754 single precision in ISO 32000-1, slightly larger than IEEE754 single precision in PDF/A (which I am still very sore about) and essentially unlimited but IEEE754 single or double recommended in ISO 32000-2. However values are not stored in IEEE754 in PDF, they're serialised as text.

My point is you're not going to get any more accuracy when converting to/from PDF with this suggestion. I would not expect more than 5 d.p. of resolution for any numbers stored in PDF, and if I wanted to generate a halftone pattern like yours, I would scale up by a factor of 1000 or so in both formats.

[SieuDoTia]

I convert from PNG to SVG direct by program I create. I want new choice, use SVG replace PDF. When create that SVG picture, I change my program use 5 digits decimal precision. That seem work good.

Multiply by 1000 and use viewBox is good idea. I will try it. If no more problem I will close this If multiply by 1000, should I remove three digits after decimal point for keep file size same?

[SieuDoTia]

Here is same SVG image file with your scale 1000 idea and viewBox. It still have 5 digit precision after decimal point and file is only ≈15% larger.
http://www.mediafire.com/file/h1kvr4r9bpkbxic/line-screen_192lpi_1000.svg/file

Please add it to https://gist.github.com/ (I think it not work because my browser is too old and I can't upgrade). Sorry about garbage file form MediaFire. If any other person have this problem in future, they can read this discussion.

[faceless2]

Done: https://gist.github.com/faceless2/cb6cd31f5623e8fb1a8d15e14395ca28

[svgeesus]

I see where you're going with this. Obviously the SVG is machine generated, it strikes me that scaling every dimension up by 1000 and set "viewBox="0 0 89000 95000" would avoid any issues you're having with float resolution.

I have seen this sort of issue come up a few times; sometimes people are unaware of resolution limits, or they are but don't see how to maximize them.

I know that SVG Tiny 1.2 had a precision requirement and SVG2 is moving towards deliberately not specifying one, but perhaps some authoring advice could be given. For example, consider

viewBox(0, 0, 10000, 10000)
viewBox(0, 0, 0.1, 0.1)
viewBox(100000000, 100000000, 100000000.1, 100000000.1)

These progressively squander the available resolution of any implementation