viewBox value 0 should been fixed on save

[Roul P.]

Maybe this is more like a request than a bug:
 A zero value disables rendering of the element. https://www.w3.org/TR/SVG/coords.html#ViewBoxAttribute (tested on FF, Chrome , librsvg)

Inkscape ignores this and the result is nothing to see: https://commons.wikimedia.org/wiki/File:A_test_SBJR_v3.svg

So I suggest to fix zero value if in the SVG header (with dependent value).

=====
Win 7 x64 , Linux Mint 64bit
Inkscape 0.91 devel 32bit and Inkscape 0.91pre4 r13712 64bit

[su_v (suv-lp)]

Please add information about OS/platform and tested Inkscape version to the bug description, thank you.

[Roul P. (perhelion1)]

@ ~suv: It's non system depending (I've Win 7 x64 , Linux Mint 64bit). It is a feature request. No viewer can show the file but Inkscape can do it, because the viewers are only W3 conform.

[Roul P. (perhelion1)]

Inkscape 0.91 devel 32bit and Inkscape 0.91pre4 r13712 64bit

[Roul P. (perhelion1)]

I've an answer from the author (Summerdrought) of this file:
" Some background information may be useful. I recently experienced a Windows 7 crash, and had a re-installation done on my hard drive, thus losing most programs including Inkscape. I think I was using Inkscape .45 or .48 . I downloaded Inkscape .91... I am using IE and the images display OK on my computer." So it seems IE can do display this graphics (not W3C conform). His operating system is Windows 7 running Inkscape .91r13725

[Alvin Penner (apenner)]

- not reproduced on Windows 7 (32 bit), Inkscape 0.91 r13725 (Jan 30 2015)
- not reproduced on Windows XP, Inkscape 0.91+devel r14569 (Jan 9 2016)

could you indicate more specifically exactly what the problem is, perhaps include a screen shot of the Inkscape window after the file is loaded?

[su_v (suv-lp)]

A viewBox width or height defined as '0' (zero) is valid SVG and should not be changed by Inkscape on save unconditionally to some arbitrary value - it could have been the intent of the author of the SVG file. A negative number on the other would be invalid SVG (see SVG 1.1 spec).

Likely you encountered one of the known regressions (or sequence of steps) which can cause Inkscape 0.91 to write a zero width (or height) unintentionally (not intended by the author of the document), as tracked e.g. in this earlier report:

* Bug #1473955 “Sticky zero width, height in viewBox attribute”
  https://bugs.launchpad.net/inkscape/+bug/1473955

Such a state of the viewBox could possibly also result from attempts to "fix" a different issue which can result in unexpected values for the document's viewBox:
* Bug #1419122 “"resize page to selection" broken in 0.91 with width="100%", height="100%"”
  https://bugs.launchpad.net/inkscape/+bug/1419122

Both issues are already fixed for the next release, and Inkscape won't allow to define a zero viewBox dimension via GUI directly. IMvHO Inkscape should not overwrite the author's intent e.g. in valid third-party or manually edited SVG files.

Likely, the underlying issue of this report is already tracked in bug #1473955 (it is not possible to tell or reconstruct in hindsight how the initial SVG uploaded to wikimedia ended up with a "0" viewBox height [1]) . With regard to the summary line of this report though, I would propose to close it as 'Won't Fix' (the requested action is not something Inkscape should do).

--
[1] https://upload.wikimedia.org/wikipedia/commons/archive/1/1b/20160114143216!A_test_SBJR_v3.svg
   viewBox="0 0 566.92913 0"

[su_v (suv-lp)]

<off-topic>
On 2016-01-14 22:38 (+0100), Roul P. wrote:
> Inkscape 0.91pre4 r13712 64bit

I would not recommend to use a release candidate version as test case for a bug report about the actual stable release, nor to use it in a production environement at all - the final stable version (r13725) was released 12 months ago, and any prerelease candidate version should be considered as unstable and obsolete.
</off-topic>

[su_v (suv-lp)]

JFTR - the affected file at wikimedia was created with stable Inkscape 0.91 r13725 - known to be affected by bug #1473955:
> inkscape:version="0.91 r13725"

Source:
https://upload.wikimedia.org/wikipedia/commons/archive/1/1b/20160114143216!A_test_SBJR_v3.svg

[su_v (suv-lp)]

Actually, current trunk (tested with 0.91+devel r14584) does indeed overwrite the original (valid) viewBox attribute on load with a newly computed one, as requested by the reporter (whether or not the drawing scale is what was originally intended would have to be determined - the viewBox width does not match anymore).

Based on tests with archived trunk builds:
- viewBox attribute unchanged: rev <= 13937,
- viewBox overwritten: rev >= 13938;
AFAICT the commit in rev 13938 implemented (intenionally, or as side-effect) what the reporter requested.

Closing the report as 'Fix committed' with milestone 0.92 for now.