No Images loaded since last Update

[saeitsystems]

No Images loaded since last Update

[igagis]

I will have a look asap

[saeitsystems]

I uninstalled the libcssdom and started a rebuild ...... I will tell you soon if this fixed the problem

[saeitsystems]

No, it didn't change a thing. Not a single image ist rendered. They are all blank, some of them completely transparent and some of them are painted black. I attached some icons for you.
icons.zip

[saeitsystems]

Ok, I'm working with VisualStudio 2019 and Windows. Looking forward to here from you (on Monday)

[saeitsystems]

Hi Ivan, I was on holiday until today. I will try the things you sugested and tell you the results

[igagis]

Ok, the svgdom version 0.3.68 is now availabale, please update and try.

[saeitsystems]

That solved my problem!!
I didn't find the decimal point, the fast float library is using but I think it's fixed to '.'

[saeitsystems]

That sounds good.
Thanks again for your good and quick support!
If you want to have a look where your libray is used:
https://www.sae-it.com/en/products/software/setit-configuration-tool.html
I must get my bosses make a donation to you.

[saeitsystems]

I didn't ask my bosses but I think this is not a problem.

[igagis]

Are all the images you get empty? Could you attach simplest SVG file you have that you get empty result for?

I've just tried it on Windows with Visual Studio on my end and it seems working OK. I have successfully rendered the FW5-24V.svg which you have sent me some time ago.
Also, the fact that you are reading SVGs from memory should not matter. And there were no any changes to that part recently anyway.

By the way, the package libcssdom was renamed to libcssom some time ago. So, in case after update you have libcssdom installed as well, you can safely remove it. But I don't think that this dangling package causes the problem.

Could you check that your lpData contains non-empty string, just to exclude that possibility?

[saeitsystems]

The data is there and seems to be valid.
When I step over the svgdom::load(lBuffer); line VisualStudio stops with this message:
> setIT V7.exe!svgdom::transformable::parse(const std::string & str) Line 166 C++

[igagis]

Well, it looks like it cannot parse some transform attribute. Could you share the SVG file you get this on?

[saeitsystems]

I just realised that I have libcssdom and libcssom installed

[igagis]

Ok, but it should not cause the problem

[igagis]

I don't think it will 😊

Looks like the issue was introduced with recent optimizations to svgdom. I have tested the libs on the test data that I have, but it of course does not cover all possible SVG files.
So, I'd need the exact SVG file you see the problem on to analyze the issue.

[igagis]

I don't see anything strange in those SVG files. I have tried rendering those under Linux and all is OK. I will try on Windows today evening, as I don't have Windows machine nearby at the moment.

[igagis]

@saeitsystems
By the way, could you meanwhile clone this repo and try building and running its msvs_solution? Just to see if it works in your environment?

[igagis]

I have just tried those SVGs on Windows with VisualStudio 2019 and all works for me.

So, could you try running the svgren test project?
Just do these steps:

1. clone the https://github.com/cppfw/svgren
2. open msvs_solution in VisualStudio 2019
3. build all for v142_Release_MD or v142_Debug_MD configuration for x64 architecture.
4. run the render_test project

you should see the menue-cut.svg image rendered in the app window.

This should tell us if there is something wrong in your environment or in your project setup.

[igagis]

The other thing you could try is printing the SVG DOM for one of those icon SVG files:

m_pImage = svgdom::load(lBuffer);
std::cout << m_pImage->to_string() << std::endl;

Then if you copy the printed XML here I could check if transform attributes are parsed correctly or not.

[saeitsystems]

I have just tried those SVGs on Windows with VisualStudio 2019 and all works for me.

So, could you try running the svgren test project?
Just do these steps:

1. clone the https://github.com/cppfw/svgren
2. open msvs_solution in VisualStudio 2019
3. build all for v142_Release_MD or v142_Debug_MD configuration for x64 architecture.
4. run the render_test project

you should see the menue-cut.svg image rendered in the app window.

This should tell us if there is something wrong in your environment or in your project setup.

When I start the render_test application from command line nothing happens. When I try to debug the application I get this message:

[igagis]

Are you on 32 bit windows? 😊

[igagis]

Select x86 as target architecture.

Actually, I tried everything as 64 bit apps. I wll try 32 bit now, maybe it will reproduce the error...

[saeitsystems]

I'm working on a 64Bit Windows but our Target Application is Win32. Perhaps some things are missing for Visual Studio 2019.
I had to change the solution to VS2019 (it was still on VS2015) and the C++ Standard to C++17 It seems that you haven`t run the solution on VS2019 before?

[igagis]

I see. Local user settings like current active config and startup project are not always saved by VS201x for some reason, I mean in project files which I keep in git. I have no idea why, unfortunately microsoft products are not very command line friendly, so everything must be done via GUI and we have to rely on what VS201x does. I have run this solution in VS2019 couple of days ago :).

But anyway, I also realized that you probably have libsvgren project set as startup project (it's name is probably bold in your project navigator panel). You need to set render_test as startup project, just right click on it and select Set as startup project. After that try to run it.

[igagis]

Meanwhile, I have tried running render_test on Windows as 32 bit app in VS2019 and it works for me too.

So, looks like we need to try to debug in your setup.
Another thing to check also is that your lnLen variable holds correct buffer length. Try to print it for menue-cut.svg for example, so that we can compare it to the size of that file.

[igagis]

I had to change the solution to VS2019 (it was still on VS2015) and the C++ Standard to C++17

Er, again, after some thinking I realized that this does not look right. It should have been VS2019 solution in git for some long time. Maybe you have checked out some old version... Make sure you are on the HEAD of master branch.

[saeitsystems]

I downloaded the master branch as zip file. I'm not running git on my machine, we use svn as version control system.

[saeitsystems]

This is what I get when I dump the image as string:

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" style="clip-rule:; fill-rule:evenodd; stroke-linecap:round; stroke-linejoin:round; stroke-miterlimit:1" width="256px" height="256px">
	<g id="Schere">
		<g>
			<g>
				<path style="fill:#a0a0a0; stroke:#3d4252; stroke-width:6"/>
			</g>
			<g>
				<path style="fill:#a0a0a0; stroke:#3d4252; stroke-width:6"/>
			</g>
		</g>
		<path style="fill:#004995"/>
	</g>
</svg>

[igagis]

Just to make sure you have the latest snapshot, could you download and try this one https://github.com/cppfw/svgren/archive/d14868e.zip ?

[igagis]

This is what I get when I dump the image as string:

this is definitely not what it must be. All path's have no d attribute at all. Let me think why it could happen this way.

[saeitsystems]

I have downloaded the zip you provided and all files are identical to the ones I downloaded as master.
I compared the changes my visual studio 2019 has done to the project files:

<PlatformToolset>v142</PlatformToolset>
<LanguageStandard>stdcpp17</LanguageStandard>

[igagis]

Ok, by the way, what exact version of VS2019 do you use? Recently 16.10.0 came out, I'm using that one.
I have to run now, will get back to it in about 1-2 hours.

[igagis]

Also, please check that you have latest versions of all nuget packages. You probably have, but anyway worth making sure.

[saeitsystems]

I use VS2019 16.10.0 as well

[igagis]

I've just had a though, since you get this error:

svgdom::transformable::parse(const std::string & str) Line 166	

At line 166, it fails to parse some number. The recent optimizations to svgdom were to switch from std::istringstream to functions like std::strtof(). So, looks like in your env this strtof() fails for some reason, while in my setup it works. Can there be different version of runtime library in your setup than in mine?

[saeitsystems]

Not that I know. The parsing of float values can be a problem because of local settings for dot and komma. This is a german application and komma is the decimal seperator. In our application we use our own parse function because of these problems.

[igagis]

Ahaa, that might explain it! I'll need to use locale independent parsing then. Let me think how to fix it faster.

[saeitsystems]

What about this header only library:
https://github.com/fastfloat/fast_float

[igagis]

this looks interesting.
But first I need to reproduce he problem on my side. Do you set the german locale in your app via setlocale() or is it picked up from your system?

[saeitsystems]

I get ist from the system. I have attached a screenshot wich shows the code and that the decimal character ist ','

[igagis]

I have used the fast_float library, it seems working. It even improved performance twice more.
I will release new version of svgdom soon.

[saeitsystems]

That sounds good, waiting for the new library ........

[igagis]

yes, fast_float is locale-independent and uses . always. Thanks for reporting the issue and helping to solve it! I have added test case which sets DE locale and checks that parsing is not broken by that, so hopefully the problem will not re-appear again.

[igagis]

Looks cool! Nice to see the software is working in some product :).

I'm thinking about starting a wiki page with list of products/projects which use svgren, can I add this link there?

[saeitsystems]

You need to look into the flyer to get a screenshot from the application.

[igagis]

Great!
Yes, I had a look at the PDF already. Would be nicer if screenshot was on the web page, but this is ok too.