Re: The (new, enhanced) viewbox property

Tab, all,

I think the absolute size of a pixel is irrelevant for any use. Aspect  
ratio like 4:3 have been thrown out of the window for quite a while with  
16:10 and a wide variety of them being available. It's not the point  
really. What would be useful is to be able to set a number of px unit, so  
you don't have to work with insane amounts of decimals in your SVG  
documents as authored by wysiwyg editors.

Now you end up with 6 decimals if you have been designing with mm as units  
simply because the applications will use conversions using 90dpi. I'd  
rather be able to make clear to the application I'd like to use a number  
of pixels per unit if my out put is something else but an ancient type of  
display or fax machine. I want my files to be more readable when I have  
been using metrics so I can program my application working with these  
files a bit simpler and not end up with conversion errors due to Inch to  
mm and back calculations creating rounding errors.

True, this is mainly a problem of the editors in question, but it might be  
an idea to facilitate future generation of editors with such a setting as  
to prevent this issue once and for all.

Would be fine to set it in the root of the SVG document, but it would be  
even nicer if it could be set for different snippets of code that are  
inserted by xlink to check out the unit settings and adopt to the scale of  
the SVG document it is inserted in if needed forceScale="auto"

In print I used to work with 1200 dpi in 1994 and 2540 dpi output a bit  
later. Just tell it to the Rip and it will come out nicely calculated. If  
I'd like to create architectural drawing or technical drawings it would be  
great if I could just set the frigging px per unit and my screen would at  
least attempt to display my stuff at that resolution.

I somehow get the idea in the discussion it is lost that there are other  
reasons but screens to want to be able to set the resolution as px being  
not just pixels on a screen, but any dots in a raster. It would enable  
authors to just enforce whatever resolution they see fit to be sent to  
whatever output channel and would even allow for things like pixellation  
of your vector images (great for icon designers that want pixel output) or  
the resolution of for instance filters being calculated at such  
resolutions.

Design at 10px per mm for fast calculations and then increase it to higher  
resolutions like 75px per mm for better output results for instance?

A tool like Inkscape or Illustrator is used for more than just web design  
and screen output. Plotters, cutters, plates, you name it.

SVG is by far the best way to bridge these worlds of output with a  
singular format that can handle all.

Okay,.. missing is CMYK support, which could easily be added with  
something as simple as a colourSpace="CMYK" attribute making clear that  
fill="30%,50%,30%,10%" would be valid, but hell. Hexachrome might be  
similar but than with 6 values. Also nice for those that use some varnish  
on top.

SVG fonts were sadly missing functionality for a large number of writing  
systems, but if fonts can be embedded using base64 encoding, at least  
there is the Flashy way of doing things with that. Just throw in some  
binary code for good measure. SVG v3 may address that issue I guess.

But the point I'm trying to make here is that the screen pixel is  
irrelevant because of its unreliability. Maybe in a few years that will be  
fixed and in that case it will be quite handy to have it specced already.

I see a lot of references to CSS these days, but CSS is irrelevant to  
anything but web browsers. Let's not leave functionality out of SVG what  
cannot be done out of browser context due to such omissions.

Cheers,

Jelle Mulder


On Wed, 08 Jan 2014 06:08:57 +0800, Tab Atkins Jr. <jackalmage@gmail.com>  
wrote:

> On Tue, Jan 7, 2014 at 4:14 AM, Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>  
> wrote:
>> Tab Atkins Jr.:
>>> No, CSS applies, the language as it stands, not any obsolete snapshots
>>> of the standard like 2.0.
>>
>> No, SVG 1.1 clearly references the CSS 2.0 recommendation.
>
> Doesn't matter.  The living CSS is what is actually used.  That
> reference is a spec bug, nothing more.
>
>>> Once again, you misunderstand what was actually defined by CSS.  I'm
>>> far past the point of hoping to educate you on this matter, but for
>>> the edification of other readers, here's how CSS deals with units:
>>
>> Well, as an experimental physicist I know what an absolute unit of
>> length is
>
> So does everyone else in this thread and the relevant working groups.
> That's not relevant here.
>
>>> It turns out that authors commonly assume that there is a fixed ratio
>>> between the px unit and all the physical units, especially pt.  This
>>> sometimes results in page designs that work when a particular px:pt
>>> ratio is used, but breaks (lines break unexpectedly, floats move
>>> chaotically) when a different one is used.  This means that browsers,
>>> in practice, have to fix a particular ratio of px:pt in order to
>>> render the internet correctly.
>>
>> If this happens for projects using (X)HTML+CSS, typically those
>> pages are already broken due to user-stylesheets with a required
>> minimal font size. Often one has to switch off CSS interpretation for
>> such projects at all to get some kind of interpretable presentation -
>> in several cases however it turns out, that the content is in a similar
>> way chaotic than the styling. This needs to be fixed by the authors,
>> CSS cannot fix nonsense of authors.
>
> Yes, minimum font sizes cause similar problems.  They're also opt-in,
> controllable, and less common than monitors with a px:pt ratio other
> than 4:3.
>
>>> The most common ratio, and the one CSS mandates, is 4px = 3pt, due to
>>> most monitors using 96 dpi for many years.
>>
>> I used many monitors in the past years, none of them had 96 decive  
>> pixels
>> per inch. Most older monitors have about 120 device pixels per inch  
>> (CRT),
>> for notebooks I have 72, 99, 120 in use.
>
> The ratio that Windows reported was, for many years, 96.  I'm well
> aware that there were other types of ratios.  96 was by far the most
> common reported ratio, which is why the 4:3 ratio was assumed by
> authors.
>
> We didn't pull this out of nowhere.
>
>> There seems to be a need for authors to indicate, whether size matters
>> or not for presentation.
>
> Regardless of this, the 4:3 ratio can still hold.  You're attacking
> the ratio, which is nonsense; the absolute size of a px is
> theoretically arbitrary.
>
> *Like I said in my previous message*, implementations are allowed to
> accurately size the physical units.  Browsers have good reasons for
> not doing so by default, and for nearly all pages, the result is fine.
>
> If you'd like to have a switch in your browser that lets you calibrate
> the size of the absolute units, feel free to file a bug against your
> browser.  It's completely allowed by the specs to do so.  Please stop
> diverting every single thread about units with your misunderstanding
> over this issue.
>
> ~TJ

Received on Tuesday, 7 January 2014 23:17:54 UTC