[ 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 [EMAIL PROTECTED]
