I just did a little bit of comparison of the path before and after your widget translated it. The path data is quite a bit different (besides just going to 6 decimal places). Something about how the path is adjusted makes it work better with the path compiler, but it does increase the compiled image size.
On Tue, Sep 18, 2018 at 12:11 AM Brian Milby <br...@milby7.com> wrote: > Ok, so your results should be the same as the "trimmed" version of the > icons in this repo: > https://github.com/leungwensen/svg-icon > > For most of the icons on that site, the removal of pad is fine. There are > a few where the pad is actually important since there are multiple icons > where some are designed to have blank space. The best examples that I can > find are the WiFi strength icons in the Metro set. > https://leungwensen.github.io/svg-icon/#metro > > Since the repo contains the full SVG of the icons (in both trimmed and > untrimmed versions), if anyone needs one of these icons untrimmed, they can > go to the repo and use the full SVG file directly. I only mention this > because when I originally wrote the SvgIconTool I noticed that some of the > icons looked odd due to the padding removal. > > That demo stack and widget are very effective. I switched over to a > couple different icon sets from that site and everything works great. What > is interesting is that some of the compiled icons look better when compiled > using the template compared to the SVG file on the site. I'll need to look > at that some more to see if I can figure out why. One difference is that > the files use viewBox instead of H & W. > > Thanks for another useful widget! > > On Mon, Sep 17, 2018 at 9:56 AM hh via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> > Brian wrote: >> > I'll need to take your stack/widget and see how what it generates >> > compares to conversions from the source svg file (for the Font >> > Awesome stuff). Since you are adding back information that was >> > stripped when converting to an icon, my guess is that the results >> > should be pretty much the same. >> >> There ARE changes; >> I translate the path to have a bounding box with topleft 0,0 and >> use this translated path. >> This prevents horizotal and especially vertical offsets (which >> is often present and effectively adds unneeded transparency at top). >> >> _______________________________________________ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode >> > _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
