On Tuesday 09 July 2002 5:15 pm, David Kastrup wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> > On Tuesday 09 July 2002 3:46 pm, Jean-Marc Lasgouttes wrote:
> > > >>>>> "Herbert" == Herbert Voss <[EMAIL PROTECTED]>
> > > >>>>> writes:
> > >
> > > OK, OK... So latex will be run on this file anyway? Why not write on
> > > the log file the values you are looking for?
> >
> > I think that /this/ is the right solution. I'd like the default
> > font size and the ascent, descent info written to the log file.
> >
> > The latter is needed for those (in the future) who use dvipng and so
> > cannot extract the info from the PostScript file. It'd be nice to
> > have a common approach.
> >
> > David, could you modify preview.sty appropriately?
> > You mentioned that you already right the ascent,descent info to the
> > log file for AucTeX I believe. Could we have a lyx option too?
>
> No change in preview.sty itself needed. If you call preview.sty with
> an option "lyx", it will look for and include a file "prlyx.def".
You've been thinking ahead.
> That's similar to how the AUCTeX option is implemented. Since the
> dimensions are sort of internal stuff from inside preview.sty, I would
> prefer it if prlyx.def were ultimately distributed along with
> preview.sty instead of separately by you. That way, it would become
> easier to ensure that prlyx.def and preview.sty match. Of course,
> this would subject prlyx.def to the release cycle of preview.dtx,
> which currently has been identical to the preview-latex release cycle.
> If it turns out necessary to get a faster update, a separate release
> of preview.dtx from the rest of preview-latex might be possible.
Well that's fine too. I don't envisage LyX's requirements changing markedly
with time. Do you?
> > In turn it is passed to gs to generate an appropriately-sized image.
> >
> > Were we to use dvipng, it would still be needed.
>
> Yup.
>
> So what do you want in there eventually? The AUC TeX option outputs
> the following: it raises an error message at the beginning and the end
> of each previewed part which serves as a source special pinpointing
> with character precision. I don't know whether LyX would ever be
> interested in LaTeX itself deciding what material to preview, and this
> is just interesting if indeed LaTeX (governed by possible
> configuration files) pinpoints those materials.
>
> The error message at the end of the preview outputs the three box
> dimensions of the TeX box (which has its baseline start exactly at the
> (1in,1in) mark).
So I see:
! Package Preview Error: Snippet 1 ended.(492688+0x744653).
! Package Preview Error: Snippet 2 ended.(1441792+163840x16026923).
! Package Preview Error: Snippet 3 ended.(282168+0x377591).
! Package Preview Error: Snippet 4 ended.(1619363+449545x16026923).
Corresponding exactly to the info I currently extract from the PS file.
%%Page 1: -32890 -32890 32890 32890 492688 0 744653
%%Page 2: -32890 -32890 32890 32890 1441792 163840 16026923
%%Page 3: -32890 -32890 32890 32890 282168 0 377591
%%Page 4: -32890 -32890 32890 32890 1619363 449545 16026923
All I want in addition to this info is the font size used by latex. Could you
shove that in prlyx.def so that I can extract it from the log file.
> Now the tightpages option (which we currently don't use in
> preview-latex itself) would add additional, configurable margins to
> the box it tells PostScript to crop to. For correct ascender
> information, you would have to take those additional margins into
> account, too. The numbers are probably easiest processable as
> integers in the unit scaled points. It would also be possible to
> output them in the unit pt, but in that case the unit would be part of
> the output, and TeX's fixed point formatted numbers can contain errors
> as large as 0.5sp, which is almost 3nm. Ok ok, not so very tragic.
> The printed representation of those fixpoint numbers takes a bit more
> space in the log file than the integers, though.
Well all I'm using is this
// preview_ascent, preview_descent are extracted from the PS file
af = preview_ascent / (preview_ascent + preview_descent)
ascent = af * image_height;
descent = image_height - ascent;
so if you were to give me this ratio then I'd be happy.
Angus
