Jump to content

Vector Themes


Slice
 Share

455 posts in this topic

Recommended Posts

References using #id need the object with that id to be defined before being used because nanosvg doesn't have a forward declaration mechanism, they are just disregarded instead.

 

EDIT: Just for clarification, you are referencing #icon_1_ on line 54 but icon_1_ is not defined until line 161, etc.

Edited by apianti
Link to comment
Share on other sites

5 hours ago, apianti said:

References using #id need the object with that id to be defined before being used because nanosvg doesn't have a forward declaration mechanism, they are just disregarded instead.

 

EDIT: Just for clarification, you are referencing #icon_1_ on line 54 but icon_1_ is not defined until line 161, etc.

Thanks for notice. It is not exact reason because we have forward declaration mechanism for gradients but only for explicit shapes. Now I see it is not working for symbols.

Will be corrected soon...

 

PS. nsvg__assignGradients() should do the work

PPS. "OSicon os_mac not parsed" is another bug. shape->group is not defined

Link to comment
Share on other sites

8 hours ago, apianti said:

References using #id need the object with that id to be defined before being used because nanosvg doesn't have a forward declaration mechanism, they are just disregarded instead.

 

EDIT: Just for clarification, you are referencing #icon_1_ on line 54 but icon_1_ is not defined until line 161, etc.

Good spot and thanks for the reminder.

Though this was just a quick hand built test without thought.

 

2 hours ago, Slice said:

Thanks for notice. It is not exact reason because we have forward declaration mechanism for gradients but only for explicit shapes. Now I see it is not working for symbols.

Will be corrected soon...

 

PS. nsvg__assignGradients() should do the work

PPS. "OSicon os_mac not parsed" is another bug. shape->group is not defined

 

Thanks Slice. Working now :)

Link to comment
Share on other sites

3 hours ago, Slice said:

Thanks for notice. It is not exact reason because we have forward declaration mechanism for gradients but only for explicit shapes. Now I see it is not working for symbols.

Will be corrected soon...

 

PS. nsvg__assignGradients() should do the work

PPS. "OSicon os_mac not parsed" is another bug. shape->group is not defined

 

Only gradients and clip paths have forward declaration but no other object type. Look at nsvg__createGradientLink, nsvg__assignGradients, nsvg__createClipPath, and nsvg__findClipPath... Every object that can have the core attribute id (I think pretty much every element in an SVG can) should be able to be forward declared but the way that nanosvg is designed does not allow for this. The ids should not try to be resolved until after the entire source is parsed but that is only the case for just gradients and clip paths... Everything else is attempted to be resolved when parsed. If you look at nsvg__parseUse, just returns if the id is not found when parsed. The only other ids that are resolved are patterns in nsvg__addShape, but they are also in place and don't resolve unless already defined. I believe there is a problem with ParseSVGIcon, should it not parse the groups recursively and the shapes as well looking for the icon? I think that's why it's not finding that icon even though it is present in the SVG.

 

EDIT: I mean SVGimage->groups and SVGimage->shapes, recursively since they could be any number deep nested inside either of those.

EDIT2: Since the "os_mac" icon is a group under the "OSBadges" group, the groups directly under SVGimage->groups are never used so it can't be found even though its there.

 

 

Edited by apianti
Link to comment
Share on other sites

It will be better to sort shapes during parsing to keep different queue of shapes for different groups. In this case we can <use xlink:href="#group1"..> we can't with existing codes.

Yes, forward declaration is only for gradients and clips so we have to define symbols at very begin of svg file to be able to use it later.

About os_mac I already resolved the issue.

Link to comment
Share on other sites

I'm confused, it appears from the code that this is already happening, albeit in a totally weird way. There are two separate linked lists, image->groups and image->shapes. image->groups is a tree hierarchy of groups with shapes, the other is a list of every shape. So what I was proposing would do exactly that, recursively search image->groups first (parents then nexts, or vice versa), then if not found search image->shapes, since we may be looking for the id of a group or shape. Look here and here. Also, nanosvg is a complete mess that really barely does what its supposed to and the design is basically not sustainable for actual usage beyond a simple few paths svg that will be drawn individually. The nsvg__parseUse needs to be modified to just hold a link reference to the id it's looking for and then assign/create the objects after parsing like with gradients. It also does not search for any id that doesn't belong to a symbol or path, which is incorrect, as you stated.

 

EDIT: Also you appear to be directly modifying the linked list for shapes, instead of duplicating the list for rasterization.

Edited by apianti
  • Thanks 1
Link to comment
Share on other sites

I proposed to exclude shapes from list that already rendered to speedup parsing. Yes, I know it is dangerous because we can't search one shape twice. But I think it will not happen.

I agree it will be better to sort shapes initially making lists by every group but it requires more overthinking.

Link to comment
Share on other sites

You could maintain a separate list of already rendered shapes, and search that first then or the use element makes no sense, it needs to be able to use shapes multiple times. I am pretty sure that the groups are already sorted, at least from looking at the nanosvg source that's the way it appears to be working but just upside down, the inner most groups point towards the outer most. Truthfully, I really don't think he thought about how to design before he ran into each individual problem then solved them in ways that would not require changing what he'd already done. This resulted in a lot of incorrect behavior.

  • Like 1
Link to comment
Share on other sites

I've been having trouble creating an image using symbols that renders correctly in both Clover and Illustrator. If an image fit together correctly in one, it would fail in another.

 

After some experiments it appears Illustrator requires the size and position of objects to be described when calling a symbol and does not take these from the symbol itself, where as Clover will take these values from the symbol which I believe is what's supposed to happen.

 

So the only way I've managed to get an image to correctly draw in both Clover and Illustrator is to add placement values when calling the symbol.

 

Basic rectangles:
Clover draws boxes correctly, but Illustrator draws all 3 boxes the same size

<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
     viewBox="0 0 128 128" style="enable-background:new 0 0 128 128;" xml:space="preserve">
     
<symbol id="SquareYellow">
  <rect style="fill:#FFFFFF;stroke:#E2DD24" x="0" y="0" width="128" height="128"/>
</symbol>
<symbol id="SquareGreen">
  <rect style="fill:#FFFFFF;stroke:#41AD51" x="16.3" y="16.3" width="95.4" height="95.4"/>
</symbol>
<symbol id="SquareRed">
  <rect style="fill:#FFFFFF;stroke:#E84325" x="35.9" y="35.9" width="56.3" height="56.3"/>
</symbol>
<use xlink:href="#SquareYellow"/>
<use xlink:href="#SquareGreen"/>
<use xlink:href="#SquareRed"/>
</svg>


Clover and Illustrator draws boxes correctly:

<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
     viewBox="0 0 128 128" style="enable-background:new 0 0 128 128;" xml:space="preserve">
     
<symbol id="SquareYellow">
  <rect style="fill:#FFFFFF;stroke:#E2DD24" x="0" y="0" width="128" height="128"/>
</symbol>
<symbol id="SquareGreen">
  <rect style="fill:#FFFFFF;stroke:#41AD51" width="95.4" height="95.4"/>
</symbol>
<symbol id="SquareRed">
  <rect style="fill:#FFFFFF;stroke:#E84325" width="56.3" height="56.3"/>
</symbol>
<use xlink:href="#SquareYellow" width="128" height="128" transform="translate(0,0)"/>
<use xlink:href="#SquareGreen" width="95.4" height="95.4" transform="translate(16.3,16.3)"/>
<use xlink:href="#SquareRed" width="56.3" height="56.3" transform="translate(35.9,35.9)"/>
</svg>


But it gets more complicated with circles. For my BGM_SVG main icon template, I've found I also need to subtract the placement values from the caller from the placement values in the symbol. Which is a pain.

 

See two files:

BGM_Icon_Template_Corrected.svg

BGM_Icon_Template.svg

 

The BGM_Icon_Template_Corrected SVG file now draws correctly in both Clover and Illustrator.

 

Link to comment
Share on other sites

In this case, illustrator has incorrect behavior. I just tested your first SVG in multiple different applications and it draws three concentric squares inside each other like it should. Illustrator does not. Maybe you might want to open a bug ticket with them, as this is not correct behavior. Attributes should absolutely be copied to the use imported objects, noted by the second SVG still having colors even in illustrator (you could always move the other attributes into the style attribute though) since it's copying the style attribute. The only situation where this is not the case is if you styled them with embedded CSS and were importing from a separate file, it does not import embedded style from the other file. This does not apply if you used an external CSS though. Although you can't currently use an external CSS in clover, or import from external files, so those points are pretty moot.

 

EDIT: The second set of icons is the same bug in illustrator. It appears it's not applying certain attributes to the use imported object, although it should be. https://developer.mozilla.org/en-US/docs/Web/SVG/Element/use

EDIT2: I see why illustrator made this mistake, because it says 

much like cloned template elements in HTML5

template elements only support global attributes. However, the example given right before that clearly shows that all attributes must be copied and it copies some attributes or the elements would not be drawn correctly ever.

EDIT3: This makes it even more evident since they did what you did and expect that it draws correctly. https://developer.mozilla.org/en-US/docs/Web/SVG/Element/symbol

Edited by apianti
  • Like 2
Link to comment
Share on other sites

18 hours ago, apianti said:

In this case, illustrator has incorrect behavior. I just tested your first SVG in multiple different applications and it draws three concentric squares inside each other like it should. Illustrator does not. Maybe you might want to open a bug ticket with them, as this is not correct behavior.

Yeah. I was surprised when I saw it as I would have thought Illustrator would be the daddy! I am running CC2018 though and have not yet updated to CC2019 so I'll need to check what happens with the most up to date version.

 

18 hours ago, apianti said:

(you could always move the other attributes into the style attribute though) since it's copying the style attribute.

Yeah, thanks for the pointer. I'll need look at that.

 

And thanks for the other notes and links.

 

I'm going to need more time to look more in to individual specifics, but for now I'm posting where I am with the symbol version of BGM_SVG. I've only currently applied it to the OSBadges and Functions. I'll work on it more when I can.

 

BGM_SVG_Symbols.zip

 

Another issue with the way I'm currently using symbols so both Clover and Illustrator show the file correctly is that macOS's quicklook (does it utilise webkit?) doesn't render the file properly. 

 

 

Link to comment
Share on other sites

Yes, I think quicklook uses webkit as it show same picture as Safari.

For example if you made an svg image with text using embedded SVG font then Safari and quicklook can show it correctly. Not Google Chrome, not IE.

Link to comment
Share on other sites

2 hours ago, Slice said:

Yes, I think quicklook uses webkit as it show same picture as Safari.

For example if you made an svg image with text using embedded SVG font then Safari and quicklook can show it correctly. Not Google Chrome, not IE.

 

Funny thing about this is that almost every major developer helped to develop webkit, including adobe and google, google still has the most number of commits in webkit but uses a forked version of their own called blink since a certain version of chrome (28? 29?). I think only apple uses the original webkit now. Yeah, embedded fonts work in almost nothing, but if you move them to a separate svg and use the @font-family syntax for css then it works, lol.

  • Like 2
Link to comment
Share on other sites

 Share

×
×
  • Create New...