Define size

[ppot]

Would be great to be able to define size of the vector in order to make tray icon for application. Like 16px.

[neauoire]

What would be an ideal UX to set the vector size?

[ppot]

I would say like the the way we set color now.
Click on the actual vector size and then set it as 16 or 32 etc.

[neauoire]

Okay, good idea. Would you prefer a zoom factor, or a target size?

…

On Mon, May 7, 2018 at 3:43 AM, Philippe Potvin ***@***.***> wrote: I would say like the the way we set color now. Click on the actual vector size and then set it as 16 or 32 etc. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABY2bnMUoPnvNx3UXZyB2pKEyzqeetimks5tvxoPgaJpZM4Tz2IW> .

[ppot]

More of a target size!

[neauoire]

So, I was thinking about adding a scale transform to the SVG, something along the lines of transform="scale(0.5)", but inferring that scale value dynamically. Think that would work for you?

[ppot]

Yes. As long as you can have a size of 16pxx16px in the final it would be fine!

[espy]

Hey, short heads up, I’m working on an experimental PR that adds a cropping frame to the guide. This generates a viewBox for the resulting svg, allowing you to more easily use the svg either as a fixed-size image or as a container-filling icon. The viewBox also actually crops the svg, so you can choose to only export a bit of your image. The svgs no longer have an absolute size, or any width or height attributes, they’ll always fill their containers while maintaining aspect ratio. If you want a fixed size, you just give the svg width and height via html attributes or CSS styles. So you’d be completely flexible in terms of scaling and sizing. That would also solve this issue, since sizing the exported svg is then super simple.

This is attacking a particular pain point I had with Dotgrid, namely that building scalable icons always required me to edit the resulting SVG to adjust the viewBox, and viewBox is super weird to wrap my head around. When I’m done, Dotgrid’s svg output will be immediately usable as scalable svg icons, hopefully without messing things up for people who use Dotgrid as a pre-Illustrator tool.

I’ll also try to make sure the png gets cropped as well, and that the cropping frame defaults to the canvas size and sticks with it unless it is explicitly resized. In that way, the current behaviour would still be the default, you’d just get a scaling svg instead of a fixed size one. If you want a fixed-size image, you’re better off with the png anyway :D

Hope that all makes sense and doesn’t add anything you don’t want to Dotgrid, @neauoire.

[neauoire]

I will totally merge that. <3

[espy]

Small update. Got it working, just needs polish and some edge case handling.

Interestingly, the svg viewBox only constrains the svg, it doesn’t actually crop it. Take this example: the yes is inside the cropping frame, and if the svg is constrained widthwise, the viewBox correctly scales the svg so that the no isn’t visible.

But currently, the svg will try to 1. maintain aspect ratio and 2. be completely visible within the available viewport, so then this happens:

If you use the svg in html though, everything’s cool, as long as there’s a container element, that will crop the svg correctly, even without overflow: hidden:

So this is still useful as far as I’m concerned.

[neauoire]

We can always build on that. I’ll have a look at your branch, I’m curious to see how you’ve implemented that :) 👁‍🗨

…

On Sep 27, 2018, at 20:44, Alex Feyerke ***@***.***> wrote: Small update. Got it working, just needs polish and some edge case handling. Interestingly, the svg viewBox only constrains the svg, it doesn’t actually crop it. Take this example: the yes is inside the cropping frame, and if the svg is constrained widthwise, the viewBox correctly scales the svg so that the no isn’t visible. But currently, the svg will try to 1. maintain aspect ratio and 2. be completely visible within the available viewport, so then this happens: If you use the svg in html though, everything’s cool, as long as there’s a container element, that will crop the svg correctly, even without overflow: hidden: So this is still useful as far as I’m concerned. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[espy]

I just added the cropping frame always staying in view when resizing the app. I’ve only really got the png cropping and storing the crop in the .grid file left to be before I open a PR.

Edit: Branch is here if you want to take a look already: https://github.com/espy/Dotgrid/tree/feat/better-svg

[neauoire]

That's awesome, I'd move the control points at the centre of the lines.
Nice work!

[neauoire]

Any update on this :)

[espy]

No time to work on it this week or next, I’m afraid. I’ll open the PR now in case you want to do the rest. As for the control points, I’d leave them on the corners, having them in the middle means you need two clicks to do most things with the crop frame instead of one. I wanted to have different handles for the frame to make it easier to find, but I won’t get around to that.

[neauoire]

Good point, and I also realized that that would put the control point between two dots on the grid for odd sized crops.