Enrico Forestieri wrote:
> Perhaps you mean that the dpi variable is *proportional* to
> preview_scale_factor. Indeed, when not setting preview_scale_factor I
> obtain dpi=112, whereas setting it to 1.02 I obtain dpi=127. However, I
> don't know the default value of preview_scale_factor (and obviously it is
> not equal to 1), so I am not able to evaluate preview_scale_factor from
> the knowledge of dpi.
0.9
In src/graphics/PreviewLoader.C you'll find:
font_scaling_factor_ = 0.01 * lyxrc.dpi * lyxrc.zoom *
convert<double>(lyxrc.preview_scale_factor);
...
cs << pconverter_->command << ' ' << pconverter_->to << ' '
<< support::QuoteName(latexfile) << ' '
<< int(font_scaling_factor_) << ' '
<< lyx_gui::hexname(LColor::preview) << ' '
<< lyx_gui::hexname(LColor::background);
This is the command used to launch the script. 'dpi' inside the script is
'int(font_scaling_factor_) outside it.
Thereafter, the metrics info is used in setAscentFractions() in the same
file.
> As regards why we need to use it twice, I don't know the way the images
> are imported. What I know is that if leave untouched the value of the
> frac variable *and* preview_scale_factor is set to something different
> than its default value, then the inlined images do not perfectly line up
> with the surrounding text.
Right. But you'll understand that I'm unhappy about making a change I don't
understand.
>> The patch looks good to me but I guess that this block in
>> legacy_lyxpreview2bitmap.py (renamed ) will need to be specialised for
>> ppm files only...
>>
>> # Crop the images
>> if pnmcrop != None:
>> crop_files(pnmcrop, latex_file_re.sub("", latex_file))
>
> You're right, I overlooked that. But it is easy to fix, isn't it ? ;-)
>
> # Crop the images
> - if pnmcrop != None:
> + if pnmcrop != None and output_format == "ppm":
> crop_files(pnmcrop, latex_file_re.sub("", latex_file))
>
>> I guess that's there's going to be some interaction between this
>> cropping and the veracity of the metric info...
>
> I don't think so. The images are cropped to the left and to the right,
> so the vertical dimensions are preserved. As the only information that is
> passed back through the metrics file is the percentage of the height with
> respect to the sum of height and depth, there should be no interaction.
It's been a long time since I last looked at this ;-)
--
Angus
