Quier Icon-O-Matic vector point limit

[kallisti5]

hvif has a limitation of 256 nodes per path, 256 paths, etc. Icon-O-Matic happily imports svg vectors outside of these constraints.

When saving an hvif, the extra data points are quietly dropped. This can result in lost work and a general feeling that Haiku/Icon-O-Matic is broken.

Since hvif is working as intended, lets try to provide the following feedback:

1) When importing an svg with more than 256 nodes per path, throw a warning dialog about limitations in the hvif format.

2) When exporting a vector as an hvif with more than 256 nodes per path, throw an error. "Paths with more than 256 nodes detected, path nodes will be truncated"

While Icon-O-Matic does support > 256 points, the end goal is generally to produce an hvif.

From a UX experience, placing a warning on import provides a better chance to catch these issues early and warn users to produce better svg graphics before they "work" on their final icons.

"Nobody likes to have to redo stuff"

[kallisti5]

Screenshot of before and after save

[kallisti5]

Side bar: I'm pretty sure what is described above is happening because I can "fix" the dropped points by re-adding some, and the same thing occurs again (dropping the points added)

[kallisti5]

Funny observation: Saving in the native Icon-O-Matic format results in:

• A document where the vector image loads correctly.
• The HVIF representation of the vector image in Tracker shows the skipped points.

So.. seems like an accidental or purposeful limitation of HVIF?

[kallisti5]

Tracker shows missing points in HVIF rendering of native Icon-O-Matic document, while Icon-O-Matic does not.

[kallisti5]

LLVM Icon-O-Matic image shown in screenshots.

[stippi]

I don't remember all the details, but HVIF is definitely limited in the regards you observe. I am certain it supports 256 styles and 256 paths at most. Probably also 256 points per path, too, since it encodes the number of points that follow in a single byte. The limitation in points especially is a bit akward and feels unnecessary. Spending only one more byte per path would have upped the point limit to 65536... This can be fixed only by introducing a new version of HVIF. Other than that, I agree there should be a message informing of the problem.

That Tracker shows an icon with missing bits for a native icon file that still contains all information is not so suprising given that it shows is of course the separate icon from an attribute of the file which is in HVIF.

[kallisti5]

I think there are speed benefits to the 256 limitation, but the need for more than 256 points in a path seems like something that will follow us for a while.

I think you can automatically merge/reduce point counts in Inkscape (checking now, ​http://www.inkscapeforum.com/viewtopic.php?t=3995), so maybe a warning when importing an svg and a error when creating points > 256 is the best solution for now?

[pulkomandy]

I would rather keep the limitation. If your icon is bitmap, just keep it as bitmap, it may even be smaller than a crappy png > svg > hvif conversion.

So yes, definitely warn about "you are doing it wrong" when this occurs. HVIF icons are supposed to be small so they fit in the "small attributes" section of the inode and can be loaded "for free" from disk. If you can't fit your icon there, you may as well use a bitmap directly.

[kallisti5]

Yeah, I was able to greatly reduce down the image by tracing the bitmap in Inkscape (and not using crappy online tools) and increasing the tolerances.

So, i'd say the solution to this one is warnings and user feedback in Icon-O-Matic. Right now the limitations quietly kick in resulting in broken hvif vectors and confused end users.

[kallisti5]

reduced vectors, better svg rendering.