In article <59bdb87215bavariasound@chiemgau-net.de>,
Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:

> http://home.chiemgau-net.de/ausserstorfer/TryDraw.html

I know close to nothing about HTML, but I guess that draw files are too
exotic for the global browsers to recognise them. Anyhow, even NetSurf and
Iris refuse to show anything from the link above - and that is RISC OS
speaking.
What if you convert the draw file to SVG first?

Kind regards,
Paul Sprangers

In article <59bdbccfe4Paul@sprie.nl>, Paul Sprangers <Paul@sprie.nl>
wrote:
> In article <59bdb87215bavariasound@chiemgau-net.de>, Alexander
> Ausserstorfer <bavariasound@chiemgau-net.de> wrote:

> > http://home.chiemgau-net.de/ausserstorfer/TryDraw.html

> I know close to nothing about HTML, but I guess that draw files are too
> exotic for the global browsers to recognise them. Anyhow, even NetSurf
> and Iris refuse to show anything from the link above - and that is RISC
> OS speaking. What if you convert the draw file to SVG first?

I just tried converting that file "Ribing" to SVG using ArtWorks2 but it
needs a little work as the roads are too thin.

http://w.tjrh.uk/temp/Ribing.svg

I find it better usually to use bitmaps to save having to re-edit things
like this. IIRC Fresco used to handle Draw files in web pages.

--

Tim Hill
Webmaster, https://timil.com

websites : php : RISC OS

Tim Hill <tim@invalid.org.uk> wrote:

> In article <59bdbccfe4Paul@sprie.nl>, Paul Sprangers <Paul@sprie.nl>
> wrote:
> > In article <59bdb87215bavariasound@chiemgau-net.de>, Alexander
> > Ausserstorfer <bavariasound@chiemgau-net.de> wrote:
>
> > > http://home.chiemgau-net.de/ausserstorfer/TryDraw.html
>
> > I know close to nothing about HTML, but I guess that draw files are too
> > exotic for the global browsers to recognise them. Anyhow, even NetSurf
> > and Iris refuse to show anything from the link above - and that is RISC
> > OS speaking. What if you convert the draw file to SVG first?
>
> I just tried converting that file "Ribing" to SVG using ArtWorks2 but it
> needs a little work as the roads are too thin.
>
> http://w.tjrh.uk/temp/Ribing.svg
>
> I find it better usually to use bitmaps to save having to re-edit things
> like this. IIRC Fresco used to handle Draw files in web pages.

You would not have to re-edit them if they had a sensible width. The SVG
shows exactly what the creator of this file wanted you to see.

Those lines simply are very, very thin in the Draw file: 0.1pt, which is way
below the recommended minimum of 0.25pt for printed material. In Draw, you
do not notice, since the lines are shown without anti-aliasing, so anything
less than a pixel wide is still shown a full pixel wide.

--
Martin Wuerthner MW Software http://www.mw-software.com/

------- RISC OS Software for Design, Printing and Publishing --------

In article <mpro.r7q0j800gpj2s0gr8.spamtrap@mw-software.com>, Martin
Wuerthner <spamtrap@mw-software.com> wrote:

[Snip]

> You would not have to re-edit them if they had a sensible width. The
> SVG shows exactly what the creator of this file wanted you to see.

> Those lines simply are very, very thin in the Draw file: 0.1pt, which
> is way below the recommended minimum of 0.25pt for printed material. In
> Draw, you do not notice, since the lines are shown without
> anti-aliasing, so anything less than a pixel wide is still shown a full
> pixel wide.

Thanks Martin.

The Drawfile was created by RiscOSM.

T

In message <mpro.r7q0j800gpj2s0gr8.spamtrap@mw-software.com>
on 22 Feb 2022 Martin Wuerthner wrote:

> Tim Hill <tim@invalid.org.uk> wrote:
>
> > In article <59bdbccfe4Paul@sprie.nl>, Paul Sprangers <Paul@sprie.nl>
> > wrote:
> > > In article <59bdb87215bavariasound@chiemgau-net.de>, Alexander
> > > Ausserstorfer <bavariasound@chiemgau-net.de> wrote:
> >
> > > > http://home.chiemgau-net.de/ausserstorfer/TryDraw.html
> >
> > > I know close to nothing about HTML, but I guess that draw files are too
> > > exotic for the global browsers to recognise them. Anyhow, even NetSurf
> > > and Iris refuse to show anything from the link above - and that is RISC
> > > OS speaking. What if you convert the draw file to SVG first?
> >
> > I just tried converting that file "Ribing" to SVG using ArtWorks2 but it
> > needs a little work as the roads are too thin.
> >
> > http://w.tjrh.uk/temp/Ribing.svg
> >
> > I find it better usually to use bitmaps to save having to re-edit things
> > like this. IIRC Fresco used to handle Draw files in web pages.
>
> You would not have to re-edit them if they had a sensible width. The SVG
> shows exactly what the creator of this file wanted you to see.
>
> Those lines simply are very, very thin in the Draw file: 0.1pt, which is way
> below the recommended minimum of 0.25pt for printed material. In Draw, you
> do not notice, since the lines are shown without anti-aliasing, so anything
> less than a pixel wide is still shown a full pixel wide.
Tim has drawn our attention to this thread, as the original Draw file was
created by RiscOSM.

What were you using to view the SVG file? We tested it using Firefox on a
Linux laptop, so that we could compare it with the Draw file viewed on the
neighbouring Iyonix. In Firefox the SVG file looks very like the original
Draw file, with the only lines anyone could complain about being too thin
being the contour lines.

But Tim's complaint had been that the roads were too thin, not that the
contour lines were too thin. Aha! thought I, was he viewing it on RISC OS -
perhaps using Netsurf, and perhaps Netsurf is doing something different?
Sure enough, I find that Netsurf renders all the lines with the same (thin)
thickness, whether they are contours, roads, cycle paths or anything else!
Also, it draws dashed lines as solid, and doesn't manage to rotate the
rotated text or use the correct colour for the text.

Therefore Netsurf's SVG rendering is not as good as it should be, and I
would be very surprised if editing the SVG file could improve it. Netsurf
is clearly not paying attention to the stroke-width or stroke-dasharray
parameters when rendering <path> objects, and is ignoring the transform
matrix and fill parameters when rendering <text>. I'm afraid I don't
think there's anything I can do about that: that's something for the
Netsurf developers!

The other fault I've noticed is that all the bits of text seem to have a
linefeed character at their start. This could be a quirk of the Artworks
conversion, but it's only a problem because Netsurf attempts to render the
character (it was invisible on Firefox).

It must be the contour lines that Martin noticed, which are indeed 0.1 pt (to
avoid them dominating the map: they can be made thicker by editing the
RiscOSM style sheet). Everything else is at least 0.2 pt, and the roads are
considerably wider than that! Note that his remark about Draw not
anti-aliasing is assuming that you are not running SpecialFX.

The latest version of RiscOSM can export PNG or JPEG files of maps, both of
which are supported universally on web browsers on all platforms. So there
should be no need to try to include a Draw file of a map on a web page.

--
Hilary Phillips
Sine Nomine Software
Durham

On 20 Feb 2022, tim@invalid.org.uk wrote:

> In article <59bdbccfe4Paul@sprie.nl>, Paul Sprangers <Paul@sprie.nl>
> wrote:
>> In article <59bdb87215bavariasound@chiemgau-net.de>, Alexander
>> Ausserstorfer <bavariasound@chiemgau-net.de> wrote:

>>> http://home.chiemgau-net.de/ausserstorfer/TryDraw.html

>> I know close to nothing about HTML, but I guess that draw files are too
>> exotic for the global browsers to recognise them. Anyhow, even NetSurf
>> and Iris refuse to show anything from the link above - and that is RISC
>> OS speaking. What if you convert the draw file to SVG first?

> I just tried converting that file "Ribing" to SVG using ArtWorks2 but it
> needs a little work as the roads are too thin.

I tried Clive Semmens' !XP1DrSVG on the Ribing Draw file and it output an
SVG file that displays:

-- blank in Netsurf

-- not at all in Iris: can't display either &AFF (DrawFile) or &AAD (SVG)

-- without text in Chrome and Edge, but with message "Error on line 720 at
column 215: Encoding error. Below is a rendering of the page up to the
first error", which appears to be balking at any legend that includes a
German sharp ess.

If I replace ß by ss (and also © by C in the OpenStreetMap legend) in
Clive's output, then, lo and behold, the map displays correctly in Windows
browsers, and almost so in Netsurf where the street names are horizontal
rather than following the road.

I will let Clive know.

--
Bernard

In message <b6325bc059.boase@bernard>
on 25 Feb 2022 Bernard Boase wrote:

> On 20 Feb 2022, tim@invalid.org.uk wrote:
>
> > In article <59bdbccfe4Paul@sprie.nl>, Paul Sprangers <Paul@sprie.nl>
> > wrote:
> >> In article <59bdb87215bavariasound@chiemgau-net.de>, Alexander
> >> Ausserstorfer <bavariasound@chiemgau-net.de> wrote:
>
> >>> http://home.chiemgau-net.de/ausserstorfer/TryDraw.html
>
> >> I know close to nothing about HTML, but I guess that draw files are too
> >> exotic for the global browsers to recognise them. Anyhow, even NetSurf
> >> and Iris refuse to show anything from the link above - and that is RISC
> >> OS speaking. What if you convert the draw file to SVG first?
>
> > I just tried converting that file "Ribing" to SVG using ArtWorks2 but it
> > needs a little work as the roads are too thin.
>
> I tried Clive Semmens' !XP1DrSVG on the Ribing Draw file and it output an
> SVG file that displays:
>
> -- blank in Netsurf
>
> -- not at all in Iris: can't display either &AFF (DrawFile) or &AAD (SVG)
>
> -- without text in Chrome and Edge, but with message "Error on line 720 at
> column 215: Encoding error. Below is a rendering of the page up to the
> first error", which appears to be balking at any legend that includes a
> German sharp ess.
>
> If I replace ß by ss (and also © by C in the OpenStreetMap legend) in
> Clive's output, then, lo and behold, the map displays correctly in Windows
> browsers, and almost so in Netsurf where the street names are horizontal
> rather than following the road.
>
> I will let Clive know.

Thanks - he needs to make sure that any characters numbered greater than 127
are encided in UTF-8 in the SVG file.

There is an option in RiscOSM's general choices to use Unicode font
encodings. As it says in the manual:

As OpenStreetMap is an international project, your map may contain data in
characters other than Acorn Latin1 - especially if you go outside Western
Europe. If you have RISC OS 5 or the Unicode font manager on your computer,
you can take advantage of these Unicode characters in your map display.
However, if you wish to export Draw files using Unicode characters be warned
that not all RISC OS applications cope with them properly. The default
setting will convert all characters to Acorn Latin1 for maximum compatability
with other applications, but this will mean that some diacritics will be
lost.

I think at the moment the setting affects both the display of the map on
screen and the export as a Draw file. You might find that changing the
setting to use Unicode font encodings, regenerating the Draw file, and then
converting with Clive's utility, would result in a valid SVG file. Ideally
Clive's tool needs to pay attention to the font encoding declared in the Draw
file font table, and convert the text if needed.

We'd be happy to help with advice and code snippets if Clive wants to get in
touch.

We're aware that NetSurf doesn't display the rotated road names correctly.
When we viewed the ArtWorks generated file on NetSurf all the lines were the
same thinkness and the dash patterns for footpaths etc. were not correct.
These were fine on Firefox on a Linux machine, so the ArtWorks SVG output
looks correct.

--
Matthew Phillips
Sine Nomine Software
Durham

In message <d049b9c159.Matthew@sinenomine.co.uk>
Matthew Phillips <spam2011m@yahoo.co.uk> wrote:

> In message <b6325bc059.boase@bernard>
> on 25 Feb 2022 Bernard Boase wrote:

>> On 20 Feb 2022, tim@invalid.org.uk wrote:
>>
>>> In article <59bdbccfe4Paul@sprie.nl>, Paul Sprangers <Paul@sprie.nl>
>>> wrote:
>>>> In article <59bdb87215bavariasound@chiemgau-net.de>, Alexander
>>>> Ausserstorfer <bavariasound@chiemgau-net.de> wrote:
>>
>>>>> http://home.chiemgau-net.de/ausserstorfer/TryDraw.html
>>
>>>> I know close to nothing about HTML, but I guess that draw files are too
>>>> exotic for the global browsers to recognise them. Anyhow, even NetSurf
>>>> and Iris refuse to show anything from the link above - and that is RISC
>>>> OS speaking. What if you convert the draw file to SVG first?
>>
>>> I just tried converting that file "Ribing" to SVG using ArtWorks2 but it
>>> needs a little work as the roads are too thin.
>>
>> I tried Clive Semmens' !XP1DrSVG on the Ribing Draw file and it output an
>> SVG file that displays:
>>
>> -- blank in Netsurf
>>
>> -- not at all in Iris: can't display either &AFF (DrawFile) or &AAD (SVG)
>>
>> -- without text in Chrome and Edge, but with message "Error on line 720 at
>> column 215: Encoding error. Below is a rendering of the page up to the
>> first error", which appears to be balking at any legend that includes a
>> German sharp ess.
>>
>> If I replace ß by ss (and also © by C in the OpenStreetMap legend) in
>> Clive's output, then, lo and behold, the map displays correctly in Windows
>> browsers, and almost so in Netsurf where the street names are horizontal
>> rather than following the road.
>>
>> I will let Clive know.

> Thanks - he needs to make sure that any characters numbered greater than 127
> are encided in UTF-8 in the SVG file.

> There is an option in RiscOSM's general choices to use Unicode font
> encodings. As it says in the manual:

> As OpenStreetMap is an international project, your map may contain data in
> characters other than Acorn Latin1 - especially if you go outside Western
> Europe. If you have RISC OS 5 or the Unicode font manager on your computer,
> you can take advantage of these Unicode characters in your map display.
> However, if you wish to export Draw files using Unicode characters be warned
> that not all RISC OS applications cope with them properly. The default
> setting will convert all characters to Acorn Latin1 for maximum compatability
> with other applications, but this will mean that some diacritics will be
> lost.

> I think at the moment the setting affects both the display of the map on
> screen and the export as a Draw file. You might find that changing the
> setting to use Unicode font encodings, regenerating the Draw file, and then
> converting with Clive's utility, would result in a valid SVG file. Ideally
> Clive's tool needs to pay attention to the font encoding declared in the Draw
> file font table, and convert the text if needed.

> We'd be happy to help with advice and code snippets if Clive wants to get in
> touch.

> We're aware that NetSurf doesn't display the rotated road names correctly.
> When we viewed the ArtWorks generated file on NetSurf all the lines were the
> same thinkness and the dash patterns for footpaths etc. were not correct.
> These were fine on Firefox on a Linux machine, so the ArtWorks SVG output
> looks correct.
Yes, I just tested with !Iris browser, it works. The file opens slower
than with !NerSurf but I think it is ok. It can be saved in PNG.

--
Jean-Michel