Closed
Bug 489328
Opened 15 years ago
Closed 15 years ago
SVG generated by SmartBoard does not display correctly
Categories
(Core :: SVG, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: webmaster, Unassigned)
Details
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090419 Shiretoko/3.5b4pre (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090419 Shiretoko/3.5b4pre (.NET CLR 3.5.30729) When the Smartboard notebook software generates SVG-files, it should display each page in three ways. In a navigation bar on the left, in the main view pane and on a special sort view. Each of these are using the identical sub-document, but the main view pane remains blank, for no apparent reason. Display and navigation is scripted, the content is hard coded, though. The error console is empty, not even a warning. It works perfectly in Opera, Safari and Adobe SVG viewer. It does not work in FFox 3.5b4pre or 3.0. Background: Smartboards can generate SVG files. By default it checks for the presence of Adobe SVG-viewer, even if the browser has native support. I tried to get the Smartboard team to change this, but they won't until Firefox handles their content. Reproducible: Always Steps to Reproduce: 1. Open testcase Actual Results: Blank main view pane Expected Results: Contents should appear I have edited the testcases, trying to reduce it as much as I could, while maintaining the original feel of Smartboard generated SVG's.
Reporter | ||
Comment 1•15 years ago
|
||
Reporter | ||
Comment 2•15 years ago
|
||
Oh yes, there is a bunch of images missing in the test case, mainly arrows to switch slide. They are not essential. The demo still works.
Comment 3•15 years ago
|
||
The testcase needs to be much smaller to have any chance of figuring out what's wrong.
Updated•15 years ago
|
Keywords: testcase-wanted
Comment 4•15 years ago
|
||
(In reply to comment #1) > Created an attachment (id=373833) [details] > Test case > <clipPath id="pagedisplayclip"><path fill="none" d="M130,90 L930,90 L930,540, L130,540 L130,90"/></clipPath> There is an extra comma after 'L930,540'. Without it, the SVG file works fine.
Comment 5•15 years ago
|
||
So the example is invalid per http://www.w3.org/TR/SVG11/paths.html#PathDataBNF Feel free to raise a new bug that we should log this kind of thing in the error log though for easier debugging.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 6•15 years ago
|
||
I will take that observation to the Smartboard team. However, while working on a reduced testcase, I find the issue might still be present, even when that whole chunk of SVG is removed. When I've reduced the test as much as I can, I might reopen this bug... (I also wonder why Opera, Safari and Adobe SVG viewer "forgives" the presence of that comma...)
Reporter | ||
Comment 7•15 years ago
|
||
This is a reduced test case showing how clip-path="url(#pagedisplayclip)" is troublesome. I am working on reducing this even further, but i´t will take a while.
Reporter | ||
Comment 8•15 years ago
|
||
I'm the bozo of the day... Removing the clip path, containing the troublesome comma, while keeping a reference to that clip-path! However, doing that, the contents still show in Opera and Safari, so there is a need to clarify which behavior is correct. Perhaps someone could give me a hint, so that I could (if needed) open a bug for Webkit and submit one to Opera. Also, concerning Comment #5. Should I mention this 2nd case in the follow up bug, i.e. should the error log also include a warning that a non-existing clip-path was being addressed?
Comment 9•15 years ago
|
||
(In reply to comment #8) > However, doing that, the contents still show in Opera and Safari, so there is a > need to clarify which behavior is correct. Perhaps someone could give me a > hint, so that I could (if needed) open a bug for Webkit and submit one to > Opera. I already gave you two hints: http://www.w3.org/TR/SVG11/paths.html#PathDataBNF and I marked this bug invalid too :-) > > Also, concerning Comment #5. Should I mention this 2nd case in the follow up > bug, i.e. should the error log also include a warning that a non-existing > clip-path was being addressed? Someone has already created bug 489529 for the path parsing warning for us. You would need to raise yet another bug for a warning on a non-existent clip path.
Reporter | ||
Comment 10•15 years ago
|
||
Even though this bug is closed, I want to give some feedback on the evangelism aspect. This is from Smart Technologies support: I’ve (Lloyd from SMart) put through a request to our testing team to replicate the issue with our logging for the developers enabled – I included a request to test several language packs in case the comma is only occurring in the Swedish language pack. We had a problem with the Linux file-format using German not to long ago from a similar bug. (Something that was a decimal was being saved as a comma and really throwing off the file structure) I’ve also put through a request for the developers to revisit the SVG export code, as well as examine the JavaScript code that auto-exports with the files. Thanks for the information I’ll let you know when I hear from them – I sent them the link to your Mozilla Case as well.
Updated•9 years ago
|
Keywords: testcase-wanted
You need to log in
before you can comment on or make changes to this bug.
Description
•