Le 18/10/2016 à 12:11, racoon a écrit :
Thanks JMarc. Do I understand you correctly that you tested high res
displays and they actually create a problem with those tiny 1px spaces?
One other user tested on a HiDPI display and found that the spaces
(which use several pixels on those displays) would increase the
interline spacing. Therefore, TEXT_TO_INSET_OFFSET should not be used
vertically, or at least the value should be capped to avoid increasing
interline. Nothing terribly difficult, I guess, but it needs to be done
carefully..
Since I can't test on a high res display: would a zoom of, say, 100 %
result in the same height in pixels of a given font on high res and low
res displays?
No. On a high res display, in order to have a given text still legible,
the height of the font in pixel is more important.
To understand what happens, you should set zoom to 300% and step back a
few meters from your monitor :)
We have two strategies:
1/ like in my patch, we can define methods Inset::textToInsetOffset and
Inset::textToInsetInnerOffset maybe with shorter names :) that returns
the pixel values equivalent to 1mm and 0.5mm (according to your changes).
2/ I can provide you with methods MetricsInfo:::textToInsetOffset and
MetricsInfo::textToInsetInnerOffset that returns the pixel values
equivalent to 0.3em and 0.15em (according to your changes).
In the second case, the spacing will be larger when the font is larger,
for example in a section title. I think that this makes sense. Anyway,
the idea is to provide a method that gives a directly usable pixel amount.
Why these magic numbers, I hear you (almost) say? See the rambling below.
I suspect that I have lost you already, but I also wrote this down for
my own benefit.
The short term plan could be to do your work of using the right constant
at the right place. Then we have to use something like my patch that
makes sure that the spacing looks good on HiDPI screens too.
Sorry for the complicated explanations :)
JMarc
==========================
Appendix: some computations.
==========================
The idea of my patch is that 1 pixel on a old-school 100dpi monitor at
100% zoom is
1/100 inch (dpi means dots per inch), that is 0,254 millimeters. So the
default TEXT_TO_INSET_OFFSET value of 4 pixels is actually 1mm. Then we
can do our computations in millimeters and have LyX use the right pixel
spacing. The class Length can do this for us.
Now that I think of it, I would say that the inset spacing should be
proportional to the normal text spacing in the current font. This
information is generally available at places where one wants to compute
spacing, AFAIK. The right unit for having length that depend from
current font is 'em' (or 'mu' if you are in math formulas).
By default, the normal font has a point size of 10 (look in
preferences). A point size, if I understand correctly
(https://en.wikipedia.org/wiki/Point_(typography)#Desktop_publishing_point)
is 1/72 of inch.
Therefore, at 100dpi, a pixel is 4/3 of point. Therefore a 10 points
font would have a pixel size of 40/3 =13.333... This pixel size is
actually what one calls a em. We can get this value using the em()
method of the FontMetrics class.
All this computation to say that, with this second scheme, the value of
one pixel on a normal font size on a normal monitor would be 3/40em and
therefore the value TEXT_TO_INSET_OFFSET of 4 pixels is now equivalent
to 0.3em.
