Re: layout units in UnixPangoGraphics

Hi Martin,

msevior@physics.unimelb.edu.au wrote:
>> 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.

I have wondered about that quite a few times; the redoing of layout for
print is both time consuming and prone to producing something different
than we get on the screen.

Ideally, we should not even need to clone the classes, just have a
mechanism that would, when printing, substitute printer font for screen
font, and the tdu() function would take care of the rest when drawing. I
think on win32 this would be quite easily achieved. The problem we have
with Pango is that it is difficult to avoid caching positioning data in
device units, so we would have to do du1 -> du2 conversion on the
drawing operations; the crappy Pango API clobbers the positioning data
together with other stuff into PangoGlyphInfo so we cannot just replace
one array of positions with another, but have to replace an array of
PangoGlyphInfos with another, but it still should be doable. I should
have some time this afternoon, so I will try a couple of experiments.

Tomas
Received on Sun Oct 22 11:44:56 2006