OpenCPN RC 4.1.1301 Release

[bdbcat]

@.Paul./Chuck

So, what's going on here?

My equivalent screenshot of 50_1.KAP at Hawaii is attached. Does not look like yours. Mine looks acceptable, at least to me.

???

Dave

[bdbcat]

@jongough...

re:
The issue seems to be with icons with Text on them, i.e. Text Point has a 'T' and a '+' which don't show up. I did a conversion in inkscape to png and it worked fine, so there must be 'something' in the way I am using the wxSVGDocument to do the conversion, although I use the same method as OCPN.


I don't know SVG, but Pavel fixed a similar problem with AIS tool icon last week. Maybe a hint there.

https://github.com/OpenCPN/OpenCPN/c...9958c05b36bb73

Dave

[.Paul.]

Originally Posted by bdbcat

@.Paul./Chuck

So, what's going on here?

My equivalent screenshot of 50_1.KAP at Hawaii is attached. Does not look like yours. Mine looks acceptable, at least to me.

???

Dave

Dave,

Your screenshot looks more like the one attached below. This version of 50_1.KAP was downloaded in 2012. It has DU=254 in the KAP header indicating 254 pixels per inch. OpenCPN ignores the embedded polynomial GeoRef for this chart. My post a little earlier today has a screenshot of a new version of 50_1.KAP which was downloaded about a month ago. It has DU=400 in the KAP header indicating 400 pixels per inch. That slight change was enough to let OpenCPN use the polynomial GeoRef.

I have some more on this in Flyspray #1937.

Paul

[nohal]

The problem with text in the icons: it has to be converted to curves, otherwise cairo is not rendering it on some platforms. Also avoid using SVG optimizers like svgo and scour as the resulting files are not rendered correctly in many cases. What works pretty reliably are files saved as "Plain SVG" from Inkscape. To save size, you can often use an optimizer and then process the file in Inkscape - the resulting file is reasonable size and cairo likes it. Kind of black magick, I know...

Pavel


Sent from my iPhone using Cruisers Sailing Forum

[bobofthenorth]

@dave
I tried it both ways - OGL on and off and I can't say I saw a perceptible difference. Resolution is 1920 x 1080 and you are correct I was using raster charts all the way. I've got vector and CM93 so I'll give them both a whirl tomorrow if the weather cooperates for our crossing.

R.J.(Bob) Evans
www.bobandmarilyn.ca

[bdbcat]

@.Paul.

Hmmm, very interesting. Good catch.
Reminds us all to update our charts, even if not used for navigation.

The solution for O4.2 is clear enough. We simply reduce the max acceptable pixel error when testing the published polynomial solution. I'll change it from 10 pixels to 4 pixels. This will cause O to revert to the calculated least-squares/projection-aware solution, at least for this chart and other similar charts that try to cover large latitude ranges with a polynomial fit.

And all will be well.

There may be others tests that we could do. But this close to Release of 4.2 I would prefer to make the smallest change necessary to fix the problem, and hopefully avoid regression issues.

It may be that for O5 we will have enough confidence in our projection system that we can drop consideration of raster poly georef coefficients entirely. This will require lots of validation....

Thanks
Dave

[jongough]

Hi,
I am trying to build this version for Windows with SVG to do some testing. However, the compile is failing as it cannot find 'cairo/cairo.h', where are these and what packages do I need to install to be able to build this version?

All I can find is MSYS2, which seems to be a unix lookalike shell, and pacman which, if it works, wants to install the cairo stuff into the unix environment. I cannot find anything that will install it for use by VS2010.

Any help gratefully received.

Thanks
Jon

[bdbcat]

@jon...

You will need the latest Windows binary build bundle, e.g.

Download opencpnplugins from SourceForge.net

Also, FYI, we don't have the SVG library build working on XP yet.

Dave

[jongough]

Pavel,
Thanks, that has now go the text on my icons showing. Shame cairo does not render this correctly. Is there a similar trick for fills? My boundary icon has a crosshatch fill pattern which shows up when looking at the files in either SVG or PNG but when displayed in OCPN just comes up as a filled area the same colour as the surrounding lines (should be dark blue lines with a red crosshatch fill).

Regards
Jon

Originally Posted by nohal

The problem with text in the icons: it has to be converted to curves, otherwise cairo is not rendering it on some platforms. Also avoid using SVG optimizers like svgo and scour as the resulting files are not rendered correctly in many cases. What works pretty reliably are files saved as "Plain SVG" from Inkscape. To save size, you can often use an optimizer and then process the file in Inkscape - the resulting file is reasonable size and cairo likes it. Kind of black magick, I know...

Pavel


Sent from my iPhone using Cruisers Sailing Forum

[jongough]

Pavel, Dave,
Seeing as there now seems to be a move to use SVG icons where we can should there be a new API call that takes the SVG file rather than the bitmap so that it can be correctly scaled?

Jon

[jongough]

Thanks,
I am building only on Win 7 at the moment. I am also keeping all the code that works without SVG in my plugin so that it can be used either way.

Jon

Originally Posted by bdbcat

@jon...

You will need the latest Windows binary build bundle, e.g.

Download opencpnplugins from SourceForge.net

Also, FYI, we don't have the SVG library build working on XP yet.

Dave

[bdbcat]

@jon...

re:
Pavel, Dave,
Seeing as there now seems to be a move to use SVG icons where we can should there be a new API call that takes the SVG file rather than the bitmap so that it can be correctly scaled?

Yes, there should be.
I'll get this in tomorrow.

Thanks for upgrading the PlugIn. It will look great!

Dave

[transmitterdan]

Originally Posted by bobofthenorth

@dave
I tried it both ways - OGL on and off and I can't say I saw a perceptible difference. Resolution is 1920 x 1080 and you are correct I was using raster charts all the way. I've got vector and CM93 so I'll give them both a whirl tomorrow if the weather cooperates for our crossing.

R.J.(Bob) Evans
www.bobandmarilyn.ca

I use a "cheap" Lenovo powered by AMD A8-6410 which is a 15W processor. Without OpenGL I found raster charts to be painfully slow to the point of being unusable. But one thing that speeds up non-OpenGL mode is to turn off Options->Display->Smooth Panning/Zooming. It seems this feature is not able to discern the system speed and it takes a long time to change scale or sometimes even to move the chart when sailing in "Auto Follow" mode.

But I see a vast difference (20X?) in performance with and without OpenGL.

If you have the Voyage Data Recorder plug-in and can supply me with recorded NMEA streams of a voyage I can use that to simulate a passage and then check for features that create other slow downs.

[rgleason]

There may be other tests that we could do. But this close to Release of 4.2 I would prefer to make the smallest change necessary to fix the problem, and hopefully avoid regression issues.

Documentation Status: Far from ready. Can they be deployed separately?

• Outline has been redone
• Getting Started section is getting better.
• Entire document needs
  • Changelogs
  • Screen Updates
  • Revised text.
  • Check all links.
• Sections needing the most work.
  • Getting Started
  • Toolbar Buttons
    • Options Setting
    • AIS
  • Charts
  • Connections
  • Plugins

It is my impression that large parts of the manual are still very applicable and illustrated very nicely. However there are some major sections that need work and the entire manual should be reviewed carefully.

This is not something one person can or should do because it needs to be done carefully and thoughtfully and it will take time.

Portions of the manual are really outdated, there are duplicates and repeat sections, and we need to work at clarifying and simplifying the documentation. We need to eliminate redundancy and be clear about where a "Jump" to the main documentation is done.

Don't have the same stuff in two places! If you need a link, use a Jump page.

This will take time, with a focus on upgrading each section.

Unless we can get an army of 5-6 skilled people working on this now. But in any event, I think to get good documentation it is unreasonable to expect it to be issued at the same time as the release.

With Bdbcat's statement, release appears to be imminent. The documentation is not ready.

[bdbcat]

Rick....

Thanks for pushing the documentation update along in parallel. It is a lot of work to keep documentation current, and I do appreciate it.

We will release O4.2 when the code is ready. I'm planning for one more smoke-test RC, and then release. This should be about 15 Jan, 2016.

So, please continue to do the best you can with the time allowed. We will snapshot the Wiki into the OCPN Release image at the last minute.

Any contributors with time available are encouraged to help Rick as much as possible.

Thanks again
Dave