I ran into an identical problem when I migrated to a system using a high DPI monitor. If I set the system DPI to the standard 96 everything was fine (though oversized on the high DPI screen.)

If this is your issue, it's because gnumeric sets row heights in pixels that are not scaled with DPI, and the font engine is correctly scaling for high DPI, so you end up with more pixels than the row is high. I couldn't find any settings to fix this (if there are, please, someone tell me.)


It's an ugly workaround, but if you want to leave your DPI settings alone, you can scale the GDK DPI down to compensate using this on the command line. You may need to adjust the scale factor (96/monitor's DPI):

GDK_DPI_SCALE=0.69 gnumeric [filename]

This will result in everything being scaled down to match the unadjusted row pixel spacing. You can then zoom to bring everything back to normal size, but all the UI elements will remain scaled down.


On 03/12/2018 01:25 PM, John R. Sowden wrote:
I am in the process of switching from LO to Gnumeric because of the very slow operation of LO. The problem I am finding is when I open an .ODS file created with LO, the row height is not automatically adjusted to match the font height. There is an "autoformat" option, but it does not seem to reference row height. The lower half of the text is cut off.

Is there a SS wide option to make the row height work with the fond used? I do not use the MS TT fonts, nor do I use MS Excell.


Thanks,

John


_______________________________________________
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list

_______________________________________________
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list

Reply via email to