282350 - SVG: <svg:path d=".. M(point1) L(point2) ... with point1==point2 is suppressing output

Status: RESOLVED WONTFIX

(Core :: SVG, defect)

Description

[Heinz Kohl]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041122 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050214

with a line of length 0 the complete path will be cancelled (no display)
e.g. not working:
<svg:path style="stroke:blue;"  d="M269.72 84.81L219.00 107.00M203.00
114.00L203.00 114.00M219.00 107.00L219.00 107.00"/>

but this would work:
<svg:path style="stroke:black;"  d="M269.72 84.81L219.00 107.00M203.00
114.00L204.00 114.00M219.00 107.00L219.00 108.00"/>


Reproducible: Always

Steps to Reproduce:
1.load given file with Mozilla SVG
2.
3.

Actual Results:  
two of 4 pathes are displayed

Expected Results:  
rest of the path should be displayed, I think.
A line of length 0 should be interpreted as a point or just as not given
(no "zero length" exception seems to be given in the SVG 1.1-specification)


I encountered this problem while testing a program of me, having trouble to find
the source of this sporadic failure. The given non showing pathes are copies of
the original source.

Comment 1

[Heinz Kohl]

Attachment: SVG xml source, showing 2 svg:path from 4

Comment 2

[Marco Perez [:mpk]]

WFM with a current libart build on FreeBSD.
This may be GDI-specific.

Comment 3

[Jonathan Watt [:jwatt]]

Attachment: simpler testcase - a red line should be displayed

Comment 4

[Jonathan Watt [:jwatt]]

Tim says this works for cairo as well as libart, so it seems it's only a problem
for GDI+. I'll mark the bug as new, but if we're going to dump the GDI+ backend
then this'll probably get wontfixed later.

Comment 5

[Heinz Kohl]

testing the "simpler testcase", I found some surprising, but strictly
reproducible details (not belonging to *this* error message):

not surprising: Mozilla SVG, Build 2005062309: NO RED LINE; also for Deer Park
and Firefox on one of my XP systems.
  (the file was loaded from a saved copy of the original attachment)

But on the second of my two XP systems:

Deer Park Alpha 1, loaded from same copy as above:
   showing no red line followed by
   ERROR MESSAGE 'cannot find the file'

Complete XP error text (sorry, german):
"D:\_LW-E_Algol\shared\_CI\errors\path-coincidental-points.svg" konnte nicht
gefunden werden. Stellen Sie sicher, dass Sie den Namen korrekt eingegeben haben
und wiederholen Sie den Vorgang. Klicken Sie auf "Start" und anschließend auf
"Suchen", um eine Datei zu suchen"

Firefox 1.04 .. on one of my XP systems I was really astonished - Firefox 1.04,
showing up "no extensions", nothing extraordinary in about:config
    same error message, but - in ancient times I'd installed the Adobe SVG
viewer plugin, which is SHOWING THE RED LINE ...
    really, this plugin from 2003 is called!! (in Firefox there's nothing to see
like "Helper Applications")

The reason for the error message may be this plugin, but there's no copy of this
plugin in Deer Park

(may there be a security hole?)

Comment 6

[Mikhail Zabaluev]

Even something as simple as <svg:path stroke="black" stroke-linecap="round" d="M100 100 Z" /> won't render a dot with the GDI+ backend (in my case, on Windows 2000).

Comment 7

[Jonathan Watt [:jwatt]]

Marking wontfix. We have no plans to continue development of the GDI+ backend.

Heinz: it seems unlikely to me that the browser not being able to find a local file is a security hole. Did you include the "file:///" protocol in the URL? Anyway, if you still have an issue can you open a new bug about that please?

Mikhail: if that really bothers you please open a new bug. I don't think it is a bug (and I doubt all UAs could be relied on to render it as you want). I feel that <circle> is perfectly adequate to be honest. ;-)

Comment 8

[Mikhail Zabaluev]

(In reply to comment #7)
> Mikhail: if that really bothers you please open a new bug.

Done:
https://bugzilla.mozilla.org/show_bug.cgi?id=322976

> I don't think it is
> a bug (and I doubt all UAs could be relied on to render it as you want).

The SVG 1.1 specification begs to differ, as quoted in that entry.

Comment 9

[Jonathan Watt [:jwatt]]

I hadn't noticed that. Thanks Mikhail.

Comment 10

[Heinz Kohl]

(In reply to comment #7)
> Marking wontfix. We have no plans to continue development of the GDI+ backend.

As I'm trying to leave XP in the direction of linux, this might set up problems only in the meantime.

To write e.g. a dot circle instead of a line of length 0 (more exactly: less than 1 pixel in the actual projection!) is impossible for me.
I would have to add an afterburner for all of my generated SVG code scanning for all lines, isolating lines which might possibly be candidates for lines of less of a pixel length, and send them separately.

But up to now, I haven't found a really usable alternative for Mozilla/GDI+ in the linux world. Seamonkey 1.0beta is working, but in a restricted manner, e.g. without markers, 1.5alpha nightly builds were working like using a 256 color mode - not usable for me (but I haven't downloaded any since a week).
Working only at home on a x86-64 with linux 64bit, I've no possibility to connect my modem, and therefore I'm seeing no possibility to send crash down reports.

There seems to be deeper differences in the exact handling of styling details between Seamonkey/linux and Deer Park/linux than between GDI+ and linux backends (micro spacing, relative heights,..); and to get the necessary Unicode fonts, whenever it might be possible, is a boring game in XP's and linux with different outcome for HTML text and SVG text despite of same font descriptions making it an ugly task to change the system and even between different computers using the same system.