For example, we currently run the layout engine at the resolution of
the output device. If you're on a screen, you're getting around
72-100 dpi of resolution in placement calculations. If you're on
Windows and the printer says its 300dpi, that's the resolution of the
math being done.
An alternative approach would be to perform all calculations at much
higher resolution, scaling down to the resolution of the destination
device for things like drawing and mouse interaction.
For the BeOS version, that final conversion could be done such that it
results in a float instead of an integer with discarded precision. I
suspect that such a difference could be hidden in the
platform-specific code for BeOS, but I have not taken the time to
prove this assumption.
Tricky, but I *think* it would yield more consistent results.
Just some additional thoughts for the issue...
--> > I've noticed that the line breaks occur in different positions when you > > change the zoom factor. Also printing is not always the same as on the > > screen. > > What is the priority for this. Is it required to be fixed for release 1.0. > > > > I'll be willing to look at this problem. > > > > My approach would be: > > > > 1) Calculate character widths using a higher resolution font size. This > > could be fixed, say 100 point, or could be based on the printer resolution. > > > > 2) When using characters widths, they would then be scaled to the screen > > taking care to avoid truncation errors. > > > > 3) When calculating positions on the screen, all positions need to change > > from whole numbers to fixed point numbers to avoid truncation problems. > > > > 4) When creating a font for displaying text, the font height needs to be > > carefully chosen. > > > > 5) Soft spacing may need to be added to character positions when displaying > > text. > > At the same time, if this type of change is being made, > I might suggest that the widths be calculated and stored > as floats rather than ints. This wouldn't really cost > much in storage space float == int32 == 4 bytes, and > wouldn't be much of a performance hit. The benefit of > course is only for the BeOS platform right now that has > some draw problems because it works in floats ... and all > those dropped/rounded decimals add up. > > Thomas > > ------------------------------------------------------------- > Thomas (toe-mah) Fletcher QNX Software Systems > thomasf@qnx.com Neutrino Development Group > (613)-591-0931 http://www.qnx.com/~thomasf
-- Eric W. Sink, Software Craftsman SourceGear Corporation eric@sourcegear.com