<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - FORMATTING Text size is not scaled correctly according to the zoom factor" href="https://bugs.documentfoundation.org/show_bug.cgi?id=108638#c18">Comment # 18</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - FORMATTING Text size is not scaled correctly according to the zoom factor" href="https://bugs.documentfoundation.org/show_bug.cgi?id=108638">bug 108638</a> from <a class="email" href="mailto:philipz85@hotmail.com" title="Yousuf Philips (jay) <philipz85@hotmail.com>"> Yousuf Philips (jay)</a> <pre>(In reply to m.a.riosv from <a href="show_bug.cgi?id=108638#c14">comment #14</a>) > Looks a bit strange the past being the duplicate. A couple of words > explaining why, would be fine. Because this has more QA work in it. > With the sample on <a href="show_bug.cgi?id=108638#c12">Comment#12</a>, after 'Optimal height' works fine with > Menu/Tools/Options/LibreOffice Calc/General - Use printer metrics for text > formatting marked, but shows the behavior in the comment without it. Yes enabling 'use printer metrics' solves the issue, but it after enabling it, the height of the row goes from 1.08" to 1.15" and 3.4 didnt have 'use printer metrics' enabled. didnt get why you had to do 'optimal height'. (In reply to V Stuart Foote from <a href="show_bug.cgi?id=108638#c17">comment #17</a>) > Setting "User printer metrics for text formatting" toggles > SCINPUTOPT_TEXTWYSIWYG and SC_UNONAME_PRMETRICS, guess that means the > default mode (without precise scaling fidelity) is necessary for performance > of the sheet? Was this introduced in 3.5 that caused the regression?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>