Draw -> SVG

The log’s here: http://clive.semmens.org.uk/RISCOS/Log.txt

Have I not got ZeroPain or something like that? How do I fix that? And if I do, will other things fall over?

Although NetSurf is starting, and accessing local files okay, it’s unbelievably slow – whereas on my old RC14 it’s very quick.

Clive Semmens:

That’s quite an old version. Its crashing due to an SSL certificate window handling bug that was fixed around Christmas time.

Try a recent build from http://ci.netsurf-browser.org/builds/riscos/?C=M;O=D

8~) That’s not surprising then – I’ve not tried it recently, not since long before Christmas, because the even older one on my limited-to-1920×1200 installation works fine, and I usually use that installation.

Many thanks – I’ll try the new one now then.

Sadly, still crashing. Not quite the same: gets a bit further, and I can actually see a list of SSL certificate failures that I can accept, but then still crashes soon thereafter. New log at http://clive.semmens.org.uk/RISCOS/Log2.txt

It’s also taking a VERY long time to get started, whereas the same version on my old RC14 starts almost instantaneously.

Is this something dodgy about the particular RC14 I’ve got, or lack of zeropain? If it’s a dodgy RC14 I can get a newer one, obviously, but that’s not trivial, and if it’s not necessary…

taking a VERY long time to get started

(10.970000) frontends/riscos/font.c:121 nsfont_init: Initialise RUfl
(64.770000) frontends/riscos/font.c:131 nsfont_init: RUfl initialised

54 seconds there is odd. Do you have lots of fonts? Or keep Scrap on a RAM disc, where the RUfl cache doesn’t presist? Does it load faster if you load it a second time.

Sadly, still crashing.

What are you actually doing? Logging into gmail? I don’t know anything about RC14 or zeropain.

I do have lots of fonts, but the same ones load fast on the older ROM build, with the same version of NetSurf. I’ve not done anything with Scrap, so on both ROM builds it’s wherever the build put it. It doesn’t load any faster a second time.

It does crash when logging into gmail, yes (on the newer ROM but not on the old one), which is what it was doing when those Log2 was generated, but it also crashes about halfway through loading NetSurf’s own home page – the one off NetSurf’s website, it loads the welcome screen off my hard drive okay. I say “okay,” but it’s very slow, whereas it’s almost instantaneous with the older ROM (same hard drive).

RC14 is Release Candidate ROM 14, dated 23/2/15. The other ROM I’ve got is a nightly (beta) build from last October. RC14 is nice and stable, NetSurf runs a treat on it, really fast to load and run. But RC14 can’t handle screen sizes > 1920×1200, whereas the later build handles 3840×2160, which is very useful.

Since other people seem to have recent ROMs running NetSurf, it looks as though I’ve perhaps got a duff ROM. I’ll get a more recent one and report.

You have updated !Boot and !System from the supplied archive of course?

Also, for use with the later ROM, you have updated your HardDisc4?

You have updated !Boot and !System from the supplied archive of course?

Yes, definitely. Did that today when I got the latest NetSurf.

Also, for use with the later ROM, you have updated your HardDisc4?

I don’t remember, but assuming I was told I should when I got that later ROM, then I would have done, yes. It comes in the same ZIP as the ROM, no?

It comes in the same ZIP as the ROM, no?

No. Seperate download.

I still probably did it, assuming it was in the instructions, but I don’t actually remember now. Will get a new ROM and HardDisc4 update.

Or is there a new release candidate expected in the near future? RC14 works okay for me (NetSurf included) and my October beta works (apart from NetSurf), so I’ll wait a little while for a new RC if so.

RC16 “should” be out soon; maybe at the SouthWest Show on the 25th.

8~) Cheers, Chris! Sadly I don’t think I can make it to the show 8~( much as I’d like to.

(10.970000) frontends/riscos/font.c:121 nsfont_init: Initialise RUfl
(64.770000) frontends/riscos/font.c:131 nsfont_init: RUfl initialised

I seem to remember RUfl took ages to initialise when I ran NetSurf from an NFS mount via Sunfish. Is the NetSurf you’re running on a remote network mount?

If you copy it to RAM disc first, is it any faster?

No, it’s on a USB hard drive – the same one whichever ROM version I’m using, with one of which NetSurf absolutely whizzes along and doesn’t crash, whereas with the other (newer, but beta) ROM it crawls for a while and then crashes. I’d just stick with the old ROM, but that limits my screen resolution to 1920×1200.

whereas with the other (newer, but beta) ROM it crawls for a while and then crashes

The same here. With October ROM, NetSurf beta can crash (or crash the system) any time. And it leaves the system unstable, with random apps crashing.

An update on !XP1Dr2SVG: I had a need for a View Box in an SVG I produced (a rather messy edge to a drawing that would have been very hard to remove without messing up the good bit). Well, I made it manually in SVG, but it warn’t easy, and I thunk, “How about a special type of rectangle you can do in Draw that will be recognized by !XP1Dr2SVG, and converted to a View Box?”

Well, paths with no fill and zero line width – rendered by !Draw as the thinnest lines available on whatever medium you’re using – aren’t rendered at all by SVG apps. So I’ve implemented a conversion of the bounding box of such a path into a View Box, and the new version of !XP1Dr2SVG is now at http://clive.semmens.org.uk/RISCOS/index.php?XP1Dr2SVG

If there are several such paths, only the top one is converted, and the rest are discarded. However, I’m going to change it so that the path you want converted must be the darkest non-black shade of grey in !Draw’s standard palette. Really, I ought to make other zero width lines without fill convert to 0.25pt lines, so they aren’t lost. 0.25pt is 1.25 pixels on screen at standard resolution, and pretty thin on printouts, albeit not as thin as a proper thin line. If you want a thinner line, specify exactly how thin in !Draw – you won’t see it on screen in SVG (unless you zoom in) but it should print if it’s thick enough for the printer’s resolution. This enhancement is not implemented yet, but will be soon.

As I’ve mentioned elsewhere, Netsurf now works fine for me – indeed all my Pi issues are sorted: big screen modes, Netsurf, Zap, all on the same installation of RISCOS. Thanks for all your help everyone!

And thanks for your software :)

Aforementioned (previous post) enhancements now implemented, cursorily tested, and up on my website at same address. “Cursorily” is accurate: if you find anything going wrong, you can email me (cliveksemmens@gmail.com, also in the help file) or post here (email may get a quicker reaction). But hopefully if there’s anything wrong at all it’s in a dark corner you’re unlikely to visit! 8~)

And now the corrupt file I uploaded in September 8~( is replaced with a functioning version… 8~)

Yep, works here on a 5.23 HV ROM dated 24th Mar 18 Pandaboard.

Thanks for a useful addition to the file format conversion tools.

Just discovered an odd bug & am now working to fix it… if you have multiple zero width, unfilled paths, the resulting file won’t parse…

D’uh. Replaced the corrupt file with an older, unfinished one on March 25th by mistake, losing some updates & introducing the bug mentioned in the last post. Now all fixed – but discovered another bug to fix, in a dark corner that won’t hit you unless you have text that isn’t converted to path and contains special characters such as & or <. Workaround: convert text to path, which is generally good practice with this software anyway (most fonts don’t match well).

But I will fix it to convert the special characters – soon.

A new update to !XP1Dr2SVG – fairly minor, just makes the .svg output a fair amount shorter and render a little quicker. Previous versions saved co-ordinates as floating point numbers with many digits beyond the decimal point, which is pointless. It now saves them with just one digit after the decimal point. This makes fine details (for example text that’s been converted to paths) smoother, when viewed at full scale, than if you have no digits after the decimal point.

It’s just conceivable that someone might want more, if they’re wanting to send the .svg scaled quite small, but still want to be able to zoom in a lot. I’m willing to make a new version where you can specify the precision required if anyone feels the need, or you could edit the BASIC yourself – look at FNxy(ptr%), which is pretty simple.

Another update: XP1Dr2SVG ( http://clive.semmens.org.uk/RISCOS/XP1Dr2SVG.html ) now makes line caps match the colour of the lines they’re attached to (as in Draw), and arrowheads match both colour and dimensions of the Draw originals.

It still doesn’t repeat the arrowheads or caps on every dash in a dashed line like Draw does – unless you’ve got round caps on both ends, when it’s the SVG default. I normally prefer to only have arrowheads on the ends, not on every dash – but it would be possible to make it optional, even on a line-by-line basis. I haven’t yet decided whether to implement this, it’s not a trivial job!

Thanks for your input.

Does !Draw make use of the Trans converters series – like !Imp !Ovn etc.

Not sure about !TextEase – I think it uses it own converters.

[Edit]
Could !Draw be made to look at what ‘Trans’ are available and one’s it understands – add them to its save list?