Bug 86856 - No pixel measurement unit
Summary: No pixel measurement unit
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: low enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevEval, topicUI
: 93059 120683 (view as bug list)
Depends on:
Blocks: Measurement-Units
  Show dependency treegraph
 
Reported: 2014-11-29 16:55 UTC by Yousuf Philips (jay) (retired)
Modified: 2024-03-27 21:34 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2014-11-29 16:55:42 UTC
In order for apps like LibreOffice Writer Web to be useful, users need to be able to set the measurement unit to pixels and this should be its default measurement unit for the app.
Comment 1 Owen Genat (retired) 2015-03-17 13:02:07 UTC
Jay, I have no issue with adding a relative (rather than absolute) unit such as pixel, however not all pixels are equal or geometrically square. I would think this poses real on-screen rendering issues. Can any expert comment further on this or can the scope of this request be clarified? Setting pixel as the default unit I would see as problematic and unnecessary.
Comment 2 Yousuf Philips (jay) (retired) 2016-02-17 03:14:13 UTC
This would benefit Draw as well, as mentioned in the OOo bug report.

I checked Inkscape and it makes it easy to switch between measurement units and has 1 cm equal to 37.795275714 pixels.
Comment 3 V Stuart Foote 2016-03-25 00:29:19 UTC
The 1cm - 37.795275714 would be for a nominal 96 ppi resolution. I think we use both 90ppi and 96ppi.

For SVG filters Xisco has implemented a 96 ppi for CSS standard (see bug 97275), so working against a nominal 96ppi (in line with CSS) might be a reasonable metric to describe a canvas--not sure how much work that might be.
Comment 4 Regina Henschel 2016-03-25 11:50:15 UTC
CSS has changed px from relative unit to absolute unit with version CSS 2.1.
https://www.w3.org/TR/CSS2/syndata.html#length-units

It is now 1px = 0.75pt in CSS2.1. That makes 96px = 1in or 1cm =[96/2.54]px, which is the value you see in Inkscape.

When we decide to implement the unit px, it should be uses as defined in CSS 2.1.
Comment 5 Jelle 2016-07-27 18:50:06 UTC
With the CCS 2.1 standard setting px as 96px/inch, it should be fairly straightforward to implement PX as a measurement unit. It would certainly help authors like me that do design of backgrounds and graphical element in pixel measures for websites and other on screen content to be able to use the same measures for instance for Impress (which I believe is mainly for on screen presentations rather than print) to use a more direct approach. 

The request has been lingering since 2004 (Issue 35835). I honestly don't get why this is such an issue. In bitmaps pixels represent points on the map. On screen it is just the amount of points horizontal and vertical. Rescaling them has been standard for the past 30 years or so. Pixels are the only measurement usable in web design and SVG vector graphics use pixels as measurement for their points in all major authoring software.

The main advantage of being able to use pixels as measurement unit would be to be able to easily import graphics from third party applications and make work flow a bit more fluent. Having to set the screen size to 10.666666666667" by 8" to simulate a 1024x768 screen isn't all that intuitive. For poor people like me who use metrics it is even worse if you have to double convert. I'm rather bad at floating point calculations out of my head.

Please help the effort to move to the paperless office by implementing pixels as units.
Comment 6 jan d 2016-08-25 17:36:38 UTC
This also concerns Draw and Impress. Draw might be used for creating graphics for the Web. In particular, it can also be useful as a Wireframing or mockup application for UI design. There, having px as unit is essential, since things like 1px wide borders or the like are not fun to specify if they need to be translated into an odd mm measure.
Comment 7 Yousuf Philips (jay) (retired) 2017-07-24 15:11:22 UTC
*** Bug 93059 has been marked as a duplicate of this bug. ***
Comment 8 Regina Henschel 2018-10-18 23:13:39 UTC
*** Bug 120683 has been marked as a duplicate of this bug. ***
Comment 9 xordevoreaux 2018-10-19 01:11:57 UTC
(In reply to Regina Henschel from comment #8)
> *** Bug 120683 has been marked as a duplicate of this bug. ***

At least if my concern has come here to bug 86856 to die a lonely death, at least I know other people had the same idea.  Lots of vector programs like Gravit and Inkscape can export to PNG with pixels as the unit of measurement, so the resistance of the LO team to consider it seems a bit odd, but I guess it is what it is. 

I wanted to use LO Draw for what I was doing in Gravit because Gravit was recently bought by Corel and is going behind a paywall for its most salient features. 

Oh well.
Comment 10 Regina Henschel 2018-10-19 09:38:43 UTC
As I already mentioned in bug 120683, you can already set the desired amount of pixel while exporting. That is not the point here. This enhancement request is about having "pixel" as unit while editing.
Comment 11 J22Gim 2024-03-27 08:02:48 UTC
Even though in electronic displays a pixel is a relative unit (and thus the final size of the image will depend on the particular device), a standard must be used to render images in web pages and for interoperability in real-world applications. Why not use those for LO as well?

These are the definitions and specs from the Cascading Style Sheets of the World Wide Web Consortium (W3C).

UNIT		NAME			EQUIVALENCE
------------------------------------------------------------------
px	pixels				1px = 1/96th of 1in
cm	centimeters			1cm = 96px/2.54
mm	millimeters			1mm = 1/10th of 1cm
Q	quarter-millimeters		1Q = 1/40th of 1cm
in	inches				1in = 2.54cm = 96px
pc	picas				1pc = 1/6th of 1in
pt	points				1pt = 1/72nd of 1in

References:
https://www.w3.org/TR/css3-values/#reference-pixel
https://drafts.csswg.org/css-values-3/#reference-pixel
https://drafts.csswg.org/css-values/#absolute-lengths
https://codepen.io/patrickhlauke/full/zqabMR/
Comment 12 V Stuart Foote 2024-03-27 13:58:49 UTC
Utility seems apparent, and we'd moved SVG px handling to 96 dpi/ppi as for bug 97275 at the 5.2 release [1]. Then Mike K. included px in the o3tl unit conversion at 15 TWIP, with seamless FieldUnit::PIXEL for ePixelValue conversions [2]

So seems like we _already_ handle the device independent pixel at the normative fixed value of 96px = 1in, lacking just the UI for input.

How much work would it be across the UI to *now* add the already CSS compliant pixel 'px' unit as an *editing* unit in the controls?

And could this be an easyhack with pointers?

Stuart

=-ref-=
[1] https://gerrit.libreoffice.org/c/core/+/21617/
[2] https://gerrit.libreoffice.org/c/core/+/110839
Comment 13 V Stuart Foote 2024-03-27 15:10:50 UTC
(In reply to V Stuart Foote from comment #12)
> ... with seamless FieldUnit::PIXEL for ePixelValue conversions

Of course that was not just the FieldUnit::PIXEL, also have 'px' as a length MeasureUnit::PIXEL defined in the o3tl conversions.