<div dir="ltr"> > Congratulations, you just found a bug in GIMP :-)<br> > When you change the resolution of the document, the type layers should<br> > keep their appearance but the real world units should be updated.<br>
 > So, for instance, if you have 40 pt type in a 300 dpi documents and you<br> > change the resolution to 100 dpi without touching the pixel count, the<br> > type layer should change to 120 pt.<br><div> > IMO, that's a bug and should be fixed. <br>
</div><div>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. ; )</div><div>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.</div>
<div><br></div><div> > Ask inkscape users about type size in pixels. :-)<br> > It's a PITA to convert real world units to pixels. Your tools should do <br> > it for you, and as fas as I know, the only way to do that is having a<br>
 > resolution reference.</div><div>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.</div>
<div>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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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...</div>
<div class="gmail_extra">So in turn, all applications which supports resolution dependent units should also support resolution in both directions.</div><div class="gmail_extra"><br></div><div class="gmail_extra"> > I don't think it's messed up. Although it's true that dpi/ppi are<br>
 > confusing terms when it comes to screens or printers, in the context of<br> > raster documents dpi and ppi mean the same  ...</div><div class="gmail_extra">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 <em>that magic number</em>.) Lets just stick with ppi ; )</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"> > Anyway, I just wanted to point out that today, 72 dpi seems more a<br> > legacy default than a thoughtful decision.</div><div class="gmail_extra">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.)</div>
<div class="gmail_extra">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.</div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.)</div>
<div class="gmail_extra">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.)</div>
<div class="gmail_extra">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.<br>
</div></div>