I’m having issues with setting my own heights in calc, if I for example set to 0.750, it changes it to 0.764, Why? why is libreoffice changing my specification?
if I try to change it again… nope, libreoffice has decided it should be 0.764 and not 0.750!
I was using v. 7.2.1, but I now updating to 7.3.1
0.75 cm can be set without problems for me and is also retained.
Version: 7.3.1.3 (x64) / LibreOffice Community
Build ID: a69ca51ded25f3eefd52d7bf9a5fad8c90b87951
CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: CL
First of all, @Hrbrgr made a great point that you didn’t even mention the unit you used.
Then, you didn’t explain anything about your workflow. How do you define the height? Using which command? E.g., was it Row Height or Optimal Height from the rows’ context menu (and what was selected in the dialog), or maybe you did that by dragging the row separators manually? Was there something in the cells of the row, and what was the cell format (like, is its content wrapped)? And did that show immediately, or after a reload - at which step, another question arises: had you used ODS format, or was it, e.g., XLSX?
@mikekaganski it uses cm, and I’m selecting 10 rows, click on them and select row height.
The cells are empty.
I’m creating 10 rows with 0.125cm increment from 7cm to 8cm, so the first 10 rows are 7.007cm, (wanted 7)the next 10 is 7.126, (wanted 7.125) then 7.250, and so on… so far its only 7.250 that got the size i wanted
it’s saved in ods
You (the OQer) missed to mention the version you are using. I would assume. it’s one of the versions that were made honest, and therefore showed the height as it actually was set resolving to 1/100 mm. Any representation on screen requires to compromise with the pixels structure, on the other hand.
To avoid further useless discussions about the necessities of rounding and related issues, recent versions seem to be allowed to lie again, and to show heights and widths only resolved to 1/10 mm (or rounded this way).
now I understand, but at the same time, more confused?
I mean, if I’m setting it to a value, it should be that value, regardless of my screen?
since I’m going to print the result (and that’s why the small 1/100mm is important)
I’m not a developer, and I don’t know all the relevant details, but I have to accept that there are more than one metrics used by any software working with abstract content used to create graphical/visible representations for different media.
You may also want to print an exactly straight line with a slope of exactly 37.457° on your sheet of paper, but you will need to accept that such a thing simply doesn’t exist. Every real represantation is an approximation, and any real printer is real hardware with a real grid. There were (and still are) very clever guys studying all the ifs and whys and creating (or having created) efficient optimizing algorithms for all that approximation. There also are still forces not ready to finally or even “just one day” abandon “pixels per inch”, “pica points”, “dots per inch”, and all nonsense of that kind. The US, e.g. joined the metre convention in 1878, but didn’t find the time since, to implement it in everyday life. The last few decades metric countries were even -based on commerial forces- pushed the wrong direction (IC measures, screen dimenioning…) to newly accept non-metric standards. To be clear, however: Also in a cleanly metric world representations would often be of limited or even poor accuracy due to necessity.
…since I’m going to print the result (and that’s why the small 1/100mm is important)
Can you please explain this in more detail, because I lack imagination. Thank you.
I missed to stress this point in my (long) comment above:
Current “good” laser printers have a point density of 1200 dpi (“dots per inch”) both main directions. This means a resolution of 0.0212 mm, and thus not sufficient to represent 1/100 mm. Along the diagonal the distance of resolved points is 0.03 mm.
An there is no “exact red” in all the world except if you define a very specific superfine spectral line of some nuclide for some quantum transition as “physically red”.
As @Lupp mentioned, one of the units used in LibreOffice is mm/100. Another (actually, it’s the primary Calc unit) is twip (1/20 pt = 1/1440 in).
The ugliness in LO is not only use of these units (we better used EMUs = 1/36 000 000 m = 1 / 914 400 in exactly), but also doing that inconsistently (UNO (and ODF mostly) uses mm/100s, internal model of Calc uses twips, they are converted right and left).
And then there was tdf#101217, which naively hoped that showing more decimals would benefit people. It only could, if we used a sane unit internally (and consistently) - but not in the current state of affairs; its proposal to increase shown decimals was implemented in 7.2, and caused tdf#144247 (and its multiple dupes), which was resolved in 7.2.5.
So … what can I say. You can’t rely on infinite precision; but what’s worse, you can’t rely even on our “native” precision (neither 1/100 mm, nor twip).
@Lupp and @mikekaganski
it is highly interesting to read your explanations. Many thanks for it.
I also assume that the comments are not directly addressed to me, but are intended for all readers.
My question is aimed at getting a little closer to the way of thinking or the problem “considered” by the OP.
PS - Off-Topic: And if one considers that a pencil stroke on paper changes its line width during the drawing of the pencil, an inaccurate stroke of a printer or plotter in a certain range is already something nice. But that doesn’t really belong here.
Basically I’m going to do a simple “form”, where a “printer” is going to put data on.
this “printer” have 7,125 mm between the lines.
if I now do lines at 7.2, the text from the printer will be 0,075 mm above the line on row 2, and 0,125mm on row 3, and finally it will intersect with the row above the current one…
@mikekaganski @Hrbrgr @Lupp So now I’ve installed 7.3.1.3.
now I was setting up the rows with an 0.10mm increase;
7,10 No! 7.11 will it be!
7,20
7,30
7,40 No! 7.41 will it be!
7,50
7,60
7,70 No! 7.71 will it be!
7,80
7,90
8,00
8,10
8,20
8,30 No! 8.31 will it be!
gah! Why why why?
I can’t see any reason why?
maskin.ods (9.8 KB)
@jobe77 , sorry for my inquiry, you really have a line printer?
If so, can you please specify the brand and type. Thank you very much.
Did you read my answer above?
OK, let me show you.
You put 7,10 mm to the box. It is converted to 1/100 mm, and it’s OK: it’s 710 mm/100. Then it gets transferred through the internals, until it reaches the document model’s row height, where it needs to be converted to integral twips, and it is 402,5197 twips, rounded to 403. Then you ask it to be shown in the dialog again. The current row height value of 403 twips gets converted to integral 1/100 mm, which is 710,85 mm/100, rounded to 711 mm/100. Then it is passed through levels of internal functions to the UI, where it gets converted to mm, which is 7,11 mm.
So the two conversions (from mm/100 to twips, and back from twips to mm/100) gave you 1 off; and note that in no case you see the actual height value used, which is neither 7,10 mm, nor 7,11 mm, but 403 twips (7,1085 mm).
HTH.
oh, now I understand… somewhat… then it would be better if the program lied and said 7.10 
thx for the explanation…
I’ve actually got several matris printers, both old and newer.
Epson LQ… something is the one that’s will be using these papers…
I lack the deep insight @mikekaganski has, but would like to stress another aspect: If you want to print (or output in any way) precisely into a position (form), you aren’t actually interested in row heights, but in the bottom positions of the printable rows. Trying to define the positions precisely based on row heights in a screen representation, you need to
If you are ready to accept and study a bit of user code, you may play with the attached.
rowVerticalProperties.ods (20.3 KB)