Re: layout units in UnixPangoGraphics - solution committed

Hi Martin,

msevior@physics.unimelb.edu.au wrote:
>> 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.
>>
>
> I totally agree and just committed code to do this. We get pretty good
> WYSIWYG now. Same number of lines per page. Lines break at the same point.
> I put in a hack for full justification. It is not as good as the old
> graphics class when priting but it is not too bad. Hopefully we can make
> this better too.
>
> There are some bugs remaining, to do with images and screen dirt and
> flicker while printing. See the commit message. This code is similar to my
> old quickPrint feature.
>
> If you think this is the wrong tack to take, revert this commit and we can
> work on something else.
>

No, I think this is the right approach. I am getting correct layout now,
but the print output is scaled down (looks like by 72/96). Any idea what
is causing it ?

Tomas
Received on Sun Oct 22 20:31:00 2006