Re: layout units in UnixPangoGraphics

>
> Hi Martin,
>
> msevior@physics.unimelb.edu.au wrote:
>> The UnixGraphics code works by allocating a font at 1440 DPI and doing
>> all
>> layout calculations at that resolution.
>>
>> The PangoGraphics code does not appears to do this. Instead you scale up
>> from the current font to the layout resolution.
>
>> This defeats the purpose of the of the high resolution font and explains
>> the small discrepencies (of the order of 1%) between the calculated text
>> widths for screen layout and print layout.
>>
>> I suggest that we also allocate a layout resolution font at 1440 dpi xft
>> font for both screen and printing and do all our width and height
>> calculations on the 1440 dpi font, then scale it down to screen and
>> print
>> resolution.
>
> We do not control the dpi Pango works with. I assume that you suggest
> using a big font at the default resolution, and using its metrics in
> place of the actual font? (That is what the old graphics class does, it
> works with dpi of 72).
>

Yes, that is what I meant.

> It might be worth a try, but with Pango things are more complicated than
> with the old graphics class. For one the glyph metric consist of three
> rather than one value, and also the metric is context sensitive, so we
> cannot cache it on per-font basis as we do in the UnixGraphics. So we
> would either have to store two sets of metric for each run, adding 12
> bytes / character to our memory consumption (and as the metric is stored
> inside larger structures it would be involved swapping them anyway), or
> scale the metric on every draw; the latter might or might not be a big
> deal.
>
> The other issue doing this is that we invariably end up with inferior
> screen rendering, as the screen font will not match the metric forced on
> it. I have been seeing differences in metric for individual glyphs
> greater than 1%, and from the win32 experience, these differences can be
> quite significant, to the point of affecting usability (e.g., gaps
> between characters that look like a space).

I totaly agree. I really like the on-screen performance of the new pngo
class. It looks great.

> I suppose the big question
> is whether by WYSIWYG we mean that the printer output matches correct
> screen rendering, or the that the screen matches correct printer output,
> for we are always trading one for the other. My personal preference is
> for the former, as I spent more time editing documents on screen than
> reading them in print.
>

I agree here too. Given the choice I would make printing match screen. To
that end I could happily live with simply ensuring lines break at exactly
the same word and that each page has exactly te same number of lines per
page as the screen.

To that end is there a simple way we can keep the current screen layout
and simply pass the printer graphics class to be printed and draw that? I
guess we somehow also need to generate printer fonts for the runs.

ie We stop rebuilding the entire layout on print?

Another possibility is to "clone" the printer layout classes from the
screen classes, rather than rebuilding then from the document model. Hmm
maybe instead of using the "format" method in fl_BlockLayout, we invent a
new method called say, "cloneFormat(fl_BlockLayout * pBlock)" which
assembles lines of eaxctly the same number of characters as the cloned
block.

Any comments on these ideas? Do you have another idea for how to solve this?

Cheers

Martin

> Tomas
>
Received on Sun Oct 22 00:30:26 2006