Since it's now America first maybe we should use 8.5 inches by 11 inches as
the default. :P
Sarcasm aside, I do find it mildly annoying to have to go into the Document
Properties every time I load an instance of Inkscape to change it (almost
always to pixels). I know this can be changed in the config directory, but
being able to change the default page size and units in the GUI seems like
a reasonable feature. Alternatively (or additionally) presenting the
Document Properties dialog on startup is the way many graphics applications
handle this. I doubt we'll find any size/unit combo that makes everyone
happy.
*Ryan Gorley*
Managing Partner | Dijt <
On Thu, Sep 21, 2017 at 9:59 AM, Eduard Braun <eduard.braun2@...26...> wrote:
Am 21.09.2017 um 13:14 schrieb LucaDC:
> Eduard Braun wrote
>
>> Hehe, we're back to the question "what is one pixel" and as far as
>> Inkscape (since 0.92) is concerned 1 px is 1/96 inch, so it is a real
>> world size and this pixel size in fact *is* the standard pixel size
>> according to CSS2. Y'all should really read Mc's posts on units. ;-).
>>
> If this sentence was as strong as it tries to appear, the transition from
> 90
> dpi to 96 dpi would have been a lot less painful. Oh, sorry, I was wrong:
> the transition wouldn't even had been necessary!
>
> "Pixel" is not listed in The International System of Units (SI), where mm
> is
> (well, m of which it's a power:
>
http://www.bipm.org/en/measurement-units/base-units.html). So you can't
> say
> that the definitions of pixel and mm have comparable weights and scopes.
> 1 mm is 1 mm. Full stop.
> I agree that today a pixel can be related to a real world size unit (1/96
> of
> an Inch), but yesterday it wasn't so who can guarantee that tomorrow it
> will
> still be?
> SI units are there not to suffer of this uncertainty so that's what I call
> _real_world_units_, not something that can be changed to fit the needs of
> a
> so quickly evolving technology.
>
I don't disagree with you, a meter (why are we using mm? ;-) ) is
certainly a better measure of length than the pixel. However - while I'm an
advocate of SI myself - it's certainly not the only measure and needs are
different. Just because *you* prefer the meter does not mean other people
work the same way. You only want to offer SI units? Great! Let's drop
inches and point, too! A user wants to design a screenshot for their full
HD screen? Let's tell them to make their document 1920x1080 mm² because "1
mm will always be 1 mm" (no wait... because the px is flawed they're
probably out of luck anyway - or should they measure their screen with a
ruler... I'm confused ;-) )
Maybe you're right and with high DPI screens becoming more and more
popular it's time to say goodbye to pixel units for most content. But for
now they still have their uses and it's not for us to decide! If an
application complicates certain usage scenarios on purpose it's bound to
upset some people and leaves a bad impression behind. I don't want that.
At the very least I think we need a possibility to select the default
template via UI (I even opened a bug about that some time ago:
https://bugs.launchpad.net/inkscape/+bug/1673608) so users can make a
choice on their own without too much hassle.
Eduard Braun wrote
>
>> personally I'd feeld a lot safer to use a px-based (unscaled) SVG as a
>> base for production than to rely on some SVG with millimeters as user
>> units that Inkscape currently implements via a viewBox scaling of the
>> whole SVG (which broke a lot of our export extensions and might just as
>> well confuse import filters in other software).
>>
> If I get this sentence right, it makes me feel you've not completely
> understood how a (current) mm document is made. What could be
> misunderstood
> in a document where mm is the unit, the page is 297x210 and you have an
> object with dimensions 10x10? Actually I can't see any "viewBox scaling of
> the whole SVG" here, unless that's how you call the viewBox function
> itself.
> Perhaps you're making a bit of confusion between px as 1/96 of an inch (as
> we've been talking up to now) and px as user-unit (as per SVG
> specifications): a user-unit is not (necessarily) 1/96 of an Inch, and
> that's what the viewBox is for: nothing strange or outside SVG
> specifications here so broken extensions or import filters are simply
> buggy.
> And as far as Inkscape (since 0.92) is concerned 1 px (in the SVG sense,
> i.e. user-unit) is not always 1/90 or 1/96 inch anymore. At last.
>
You don't have to lecture me, I'm quite familiar with what we do
internally.
The problem is not so much the correctness of the SVG (I don't argue with
that) but what other software makes of it. And while you're absolutely
right that software not properly handling the viewBox attribute should be
considered broken, it does not help our users. Do you want to tell them
"hey, Inkscape is doing everything right, here, look in the cryptic
specification users should never have to care about and see for yourself
we're not to blame?" That won't help them at all...
Also the length of this thread shows how "good a job" we're doing at
hiding all those internals from the user and giving them something they can
easily work with, regardless of their specific application.
Regards,
Eduard
Luca
>
>
>
>
> --
> Sent from:
http://inkscape.13.x6.nabble.com/Inkscape-Dev-f2781808.html
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites,
Slashdot.org!
http://sdm.link/slashdot
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel(a)lists.sourceforge.net
>
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites,
Slashdot.org!
http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel