Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drawing SVGs and viewbox/crop area #531

Open
Twornicki opened this issue Sep 13, 2019 · 6 comments
Open

Drawing SVGs and viewbox/crop area #531

Twornicki opened this issue Sep 13, 2019 · 6 comments

Comments

@Twornicki
Copy link

Hello All,
I am wondering the importance of the viewbox when creating APP-6(D) svg icons for use.

When systems implement the building block approach and combine the svgs into a single icon, do they extract the relevant lines from the svg (e.g. id="mod1") and build a complete icon or do they simply overlay them using the viewbox coordinates to line up the icons?

The picture shows how they appear in Adobe Bridge. The only difference in the svg code is the viewbox coordinates.

This leads me to thinking that having the same viewbox on all APP-6(D) icons is important to align the components of the symbol within the confines of the bounding octagon.

Adobe Bridge Screenshot

Thanks

Paul Twornicki

@Elefteriou
Copy link

Paul,
It's hard to tell from your example, because it doesn't show other icons or components. I thought we constructed and aligned the components to bounding octagons (but not drawn). The symbol creation process could include main icon, modifiers, and non-volatile amplifiers (ie don't include a speed leader until later in the display process). The size would end up being more of an system implementation or operator setting type of thing. Does that help?

@Twornicki
Copy link
Author

Twornicki commented Sep 13, 2019

Thanks George, The layering process including all those elements is correct. I am looking at the use of the SVGs to build those layers.

The two examples shown have the coordinates for the viewbox/crop area set differently. The graphic and the bounding octagon are exactly the same but as there is less white space around the second example it appears larger and this may cause misalignment of the graphic if the system relies on the viewbox coordinates to line up the symbol elements. The picture shows the graphics with the bounding octagon included.

Annotation 2019-09-13 141242

If the reference coordinates used to align the symbols are taken from the viewbox top left corner for example then the symbol elements will not overlay correctly.

@Elefteriou
Copy link

Ok, I think I understand now. I guess we shouldn't use the viewbox coordinates to line up the symbol elements. Somehow we should find a point in the viewbox, anchor/position a point of the bounding octagon, and use that anchor to position the main icon, modifiers, and amplifiers (crop the result after the full symbol is made). Is there any flexibility to not use the viewbox as an anchor, but a point inside the viewbox? You could use a formula that takes a percentage of the height/width of the viewbox, for the anchor point (and then also use the result % for the size of the octagon).

@Elefteriou
Copy link

An article on scaling svg graphics. https://css-tricks.com/scale-svg/

@ottenw
Copy link

ottenw commented Sep 13, 2019

Good Morning All,

I believe there should be a common size. Not necessarily for the whole standard, but within a symbol set or functional area (land units, land equipment, etc.) so when a symbol is being constructed (by an automated process) all components align 100% correctly without any operator intervention.

I'm not down into the weeds on SVG construction so don't have an opinion between identical viewbox size, coordinates, or offset from center of viewbox.

@joebayles
Copy link
Collaborator

@jeconley any thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants