I included a draw file to a HTML page by the line <IMG SRC="Ribing">.

From local harddisc, it is working here, but not from my web space:

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


May be that the missing extension is the problem? I have no idea what
extension .???? draw files are using.

Any suggestions / ideas, please?

Thanks in advance,

A.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:

I included a draw file to a HTML page by the line <IMG SRC="Ribing">.

From local harddisc, it is working here, but not from my web space:

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

May be that the missing extension is the problem? I have no idea what extension .???? draw files are using.

Any suggestions / ideas, please?

Your server isn't sending a Content-Type header:
curl -D headers.txt 'http://home.chiemgau-net.de/ausserstorfer/Ribing' headers.txt contains:

HTTP/1.1 200 OK
Date: Sun, 20 Feb 2022 21:22:52 GMT
Server: Apache
Last-Modified: Sun, 20 Feb 2022 12:46:50 GMT
ETag: "15414-5d87282730280"
Accept-Ranges: bytes
Content-Length: 87060

So there is no clue to the browser it's a Draw file.

If your server allows, you could rename it Ribing.aff and then make a
.htaccess file containing:

AddType image/x-riscos-draw .aff

but it depends on whether your server administrator has enabled
AllowOverride FileInfo
in the server's Apache config.

Alternatively you could ask them to put the AddType line in the server's
config for you.

Of course, that's only going to work on browsers that understand RISC OS
Draw files - just NetSurf at this point?

It seems like there are *two* MIME types for Drawfiles. https://timil.com/riscos/mimemap/mimemap
has:
image/x-riscos-draw DrawFile aff .aff
# this duplicate of above covers a !Netsurf requirement:
image/x-drawfile DrawFile aff .aff

so I'm not sure which one is the better one.

Anyway, converting it to SVG is the cross-platform answer.

Theo

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 --------

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <Ain*-YkHy@news.chiark.greenend.org.uk>,
Theo <theom+news@chiark.greenend.org.uk> wrote:

Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:

[...]

Alternatively you could ask them to put the AddType line in the server's config for you.

Thanks.

Of course, that's only going to work on browsers that understand RISC OS
Draw files - just NetSurf at this point?

That's fine. I like the idea.

Is it possible to put StrHelp files to the Internet and to read it there (direct online) with StrongHelp without the need of first downloading
the files (with other tools)?

A.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:

Is it possible to put StrHelp files to the Internet and to read it there (direct online) with StrongHelp without the need of first downloading
the files (with other tools)?

StrongHelp itself doesn't to my knowledge have the ability to download files from the internet.

There is software called sh-cgi that allows StrongHelp files to be viewed as web pages:
http://www.kyllikki.org/software/sh-cgi/
but it's something that needs to be set up on the server end.

(I seem to remember it was somewhat rudimentary)

Theo

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)