Subject: Re: UT_PAPER_UNITS_PER_INCH too small (RESEND)
From: Eric W. Sink (eric@sourcegear.com)
Date: Wed Dec 08 1999 - 10:37:57 CST
[ RESEND: I sent this once and it seems to have failed. My apologies
if you get this twice. ]
> What are the problems with increasing this number? Will it actually help
> anything? I don't know the layout code well enough to guess.
This value is not nearly as useful as it looks. Increasing it will
not solve the underlying problem.
UT_PAPER_UNITS_PER_INCH is sort-of a leftover from a previous design
iteration of the layout engine. I think it gets used for storing
internal representations of the margin width.
It does not affect the resolution at which the layout engine operates.
The good news is that the layout engine does not care very much about
what resolution it is using. It is possible to fix our WYSINWYG
(What-You-See-Is-NOT-What-You-Get) problems with a set of changes
which are *mostly* localized in the GR_Graphics layer.
I think. ;-)
GR_Graphics serves as a graphical device context in much the same way
that this concept is used in many platform APIs. In this case, it has
only one concept of resolution. If GR_Graphics is connected to a
screen as its destination device, then its resolution is going to be
somewhere in the vicinity of 100dpi. It will return all of its font
metric queries to the layout engine using that resolution. This is
Bad.
GR_Graphics will need to have two resolutions: one virtual, and one
real.
We need to get the layout engine consistently running at the virtual
resolution, regardless of what the real resolution is. Try 1440dpi,
or something like that. This means that the GR_Graphics needs to
report font metrics scaled for the virtual resolution size.
BUT, when the time comes to actually render to the device, the
GR_Graphics will need to know what the *real* resolution of the target
device is, and scale things accordingly.
Screw case: Mouse clicks. When a mouse click occurs, you'll need to
scale the coordinate system backwards.
Screw case: Scrolling. I think something similar will need to be done
for scrolling.
Screw case: Printing no longer needs a re-layout. Currently, when we
print, we construct an entirely new layout object with a new
GR_Graphics. If we always run layout at 1440dpi, then we won't need
to do this anymore. This should save a lot of memory at print time.
It will also eliminate the possibility that pagination will be
different on screen vs. paper.
Screw case: Fonts. Currently, the fonts used for measurement are the
same fonts used for rendering. With a dual resolution scenario, this
will no longer be true. For each font used, we'll have to keep two
copies. One is used for measurement, and it is running at 1440dpi.
The other one is used for actual drawing, and it is scaled at the dpi
of the actual target device. This bit of magic should be hidden
inside the GR_Graphics.
I don't have the bandwidth right now to tackle this problem, even
though the longer this email gets, the more it sounds like fun. :-)
But, if I were going to attack this project, I would do this:
- First, look at all of the code which handles zoom. There are two
possibilities: either this code is useful in solving the problem at
hand, OR, solving the problem at hand will break this code. :-)
- Change the layout engine so it no longer gets its resolution from
the GR_Graphics. Doing so is not useful. We always want the layout
engine to run at 1440dpi. In fact, the information should flow the
other way. The layout code should be telling the GR_Graphics what the
virtual resolution is, so that measurements can be scaled
appropriately.
- Pick one of the GR_Graphics implementations for screen (such as the
GDK version) and alter it to scale from a 1440dpi coordinate system to
the actual coordinate system.
- Do the same thing for the postscript implementation of GR_Graphics.
This should be easier than the screen versions.
- Find the printing code which generates a duplicate layout targetted
for a printer-based GR_Graphics. Rip this out. The new code should
simply use the current layout to render to the new printer-based
GR_Graphics. Right now, I don't think it's possible to give a new
GR_Graphics instance to a layout object, so you'll need to fix that
class. When you're done, put things back the way they were.
- Leave everything else as it is now. Rebuild. Fix bugs until you
can print true WYSIWYG.
- Then, figure out if mouse interaction, selections, scrolling and
zoom are broken. Probably, all of them are. Fix one. Repeat. :-)
- Finally, send mail to abiword-dev explaining how the actual steps to
fix this problem were different from the ones that Eric predicted.
:-)
-- Eric W. Sink, Software Craftsman SourceGear Corporation eric@sourcegear.com
This archive was generated by hypermail 2b25 : Wed Dec 08 1999 - 10:54:49 CST