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.
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.
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.
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.
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.
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.
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.
*** Bug 93059 has been marked as a duplicate of this bug. ***
*** Bug 120683 has been marked as a duplicate of this bug. ***
(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.
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.
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/
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
(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.