[CREATE] [Mypaint-discuss] Resolution information in ORA

[Sebastian Wahl]

 > Congratulations, you just found a bug in GIMP :-)
 > When you change the resolution of the document, the type layers should
 > keep their appearance but the real world units should be updated.
 > So, for instance, if you have 40 pt type in a 300 dpi documents and you
 > change the resolution to 100 dpi without touching the pixel count, the
 > type layer should change to 120 pt.
 > IMO, that's a bug and should be fixed.
Like finding bugs in open-source software is a challenge. Let us check for
it again in a year and see it still being there. ; )
I think that should be a fixed as well, but if not even Gimp gets it right,
then what about the myriad of minor applications out there? It would be bad
if they just wrote the pt size without even considering if it was correct.
The idea with using pixels was that even if the application misunderstands
how pt should be used, the size would still be correctly stored in the file
if they just store the size they are actually rendering with.

 > Ask inkscape users about type size in pixels. :-)
 > It's a PITA to convert real world units to pixels. Your tools should do
 > it for you, and as fas as I know, the only way to do that is having a
 > resolution reference.
I'm not talking about the UI, the UI should do whatever the users want, not
what is specified in some random format's specification. I do not see
OpenRaster as something is supposed to be edited by hand, so I do not see
that as being a problem.
What I'm suggesting is that OpenRaster should define a base-unit and define
everything by that. (And since it is mainly raster graphics, pixels makes
most sense as a base-unit.) If an applications wants to display resolution
dependent units to the user, that is fine, they just shouldn't expect every
other application to support that unit and instead use the base-unit (only)
when storing it in the file. If it use a static typesetting ppi, or uses
the documents ppi, other applications does not need to care.

But thinking about it, it actually have a difference as normally we only
talk about square pixels, but if horizontal and vertical resolution
differs, pixels are rectangular. (Interestingly, Gimp does support this
with font rendering, but the height is still wrong.) So pixel as a
base-unit might cause confusion with aspect ratios anyway...
So in turn, all applications which supports resolution dependent units
should also support resolution in both directions.

 > I don't think it's messed up. Although it's true that dpi/ppi are
 > confusing terms when it comes to screens or printers, in the context of
 > raster documents dpi and ppi mean the same  ...
Yeah, until people suddenly start talking about printing/printers which are
using the same unit, but for something entirely different. A unit that can
mean pretty much everything depending on what you are talking about should
be discouraged. (I wouldn't be surprised if 300 dpi came to as a
misunderstanding and simply stayed in peoples memories as *that magic
number*.) Lets just stick with ppi ; )

 > Anyway, I just wanted to point out that today, 72 dpi seems more a
 > legacy default than a thoughtful decision.
Indeed. I do think 300 ppi is a poor default though. The initial value
should imo be the resolution it is authored in. So if that is in a graphic
editor, it should be resolution seen when viewed at 100% on the author´s
monitor. (I do not see the point of keeping pt size consistent with image
resolution unless the size when viewed on the monitor is the same as when
printed.)
Using that logic, the default should be the most likely resolution in the
settings where OpenRaster images are authored in, but not saved in the file.
I don't know any image editors that displays 100% based on both the image
resolution and monitor resolution (which is likely incorrect anyway), and
defaults to 300 ppi. (But I don't know that many to be honest.) That leaves
the editors which displays 100% with a 1:1 ratio to monitor pixels, and I
do not think there are that many people out there yet which have 300 ppi
monitors.

The main problem really is that until a few years ago, pretty much any
computer monitor had a resolution of 72-96 ppi, and very few applications
actually cared about it when the difference was that small. Now that there
suddenly are monitors with 200+ ppi, we are starting to see the issues when
both the web and OS'es assumed the resolution to be pretty consistent.
(Both Windows and OSX scales applications unless they use some custom API,
and srcset was recently added for HTML. Don't know the plans for Wayland.)
In a few years this situation should have improved, but for now I do not
believe we can find a sensible default. And unless we really have a good
reason to change it, lets use the commonly agreed on default. I do suspect
72 ppi will be used for applications which does not support the proprietary
API though, so if the user have specified the monitor resolution to the OS,
it will actually be shown in the correct size. (Or perhaps Windows will use
96 ppi for whatever reason, ruining it anyway.)
Personally I feel it is better to leave the default to "unspecified" to
tell applications explicitly that either resolution makes no sense (for
example images from digital cameras) or that it is unknown. A printing
application could then for example gray out the "real size" option and
require the user to explicitly select a resolution/size. But if we need a
typesetting resolution this either conflicts, or requires a special case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/create/attachments/20140301/1bfd9af7/attachment.html>