[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Extra font scaling? (Re: koffice/kspread)
From:       Stefan Nikolaus <stefan.nikolaus () kdemail ! net>
Date:       2007-01-16 20:58:55
Message-ID: 200701162200.32937.stefan.nikolaus () kdemail ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday, January 16, 2007 09:01:47 PM Thomas Zander wrote:
> Ok, I took a look at this and the first thing I noted is that your document
> inherits from the KoZoomHandler.
> Thats a bad idea, you should have zoomHandler per view (and another for
> printing) since the zoomhandler is there for one thing only; to convert
> from the internal size (in pt) to the size/resolution of the view.

Yes, that's in for a long while. It has to do with the KPart embedding.

> > To what extend is it incompatible? If I insert a table with a specific
> > size, I would like to specify how many rows/cols the table gets, but it
> > does not affect the font size. At least not right after insertion. Maybe
> > flake offers a per shape zoom/rescale, but this scaling should not be
> > done on insertion, but afterwards, shouldn't it?
>
> Right.
> What I expect is that a new sheet is created and the sheet has cells with
> each cell having its specific size.  The size is determined by the fontsize
> which you copy from the size of the kde-configuration.
> This size is in points. Not in pixels. Meaning that if I have a 9 pt font
> as standard font, my cell will be about 9pt tall.
>
> This seems to actually happen already, as when I insert a sheet in KWord
> and place it next to a manually typed '42' in a text shape, they are of
> equal size.

That's because both, KSpread and KWord, are wrong. :( Look below.

> As KoShape::resize() is virtual you can choose to scale the sheet or adjust
> the zoom.  All options are open, so just ignore that part as user feedback
> can instruct us what is best later.
> For this situation I don't think that scaling/resizing are relevant.
>
> > I can also insert a text shape with a certain dimension; the font size is
> > the same as in all other text shapes - regardless of the size. It also
> > differs from the UI's one. The text gets truncated, if it does not fit
> > into the shape, that's all.
>
> Agreed.
> If I set a font in my textShape of 12pt it will come out a certain number
> of pixels when showing it at 100%. The number of pixels is calculated based
> on the X11 DPI settings.
> Now when I set a font in my KDE settings for my menus the same process
> happens, based on the same variables. The effect is the same. I just
> verified and in KWord it is indeed what I see happening.
> If that's not what is happening in KSpread, something strange is going on.

Well, for me it's not happening in both apps. You have not occasionally a X 
dpi value of about 72? Then you'd get a factor of ~1.0, that's used for 
QPainter::scale. The more deviation from 72 the worse.

> > The printing indeed would cause problems with renormalizing the font size
> > to fit the fonts of the UI.
> > What bothers me is, that I choose Arial, 10 pt for the UI and the same in
> > KSpread and see different sized letters.
> > But I've changed it: the renormalization is gone. Let's see, if anyone
> > complains.
>
> I'm not sure what renormalization is, but you should not need it, flake is
> designed to have a completely seperated model and view. So _everything_ you
> do is in internal coordinates and sizes and only painting will get a
> KoViewConverter.
> It would indicate there are problems when your data structures still use
> zoom levels. Like Borders still do in KSpread. I assume that those just
> have not been converted yet ;)

Good catch. 

> > > So, one solution is to alter the zoom level you call '100%'. This is
> > > very much what Krita also has. A pixel-for-pixel zoom mode instead of
> > > what we normally use.
>
> Seems I was giving a wrong advice; didn't have all the variables.
>
> I just took a long look at KSpread and figured out the problem.
> KSpread uses the normal QFont constructor which implicitly applies the X
> dpi. Then on painting we again apply this and thus things look wrong.
>
> If I'm correct then the solution is to have all QFont and QFontMetrics
> constructors use a special PaintDevice.
> I'll move it from KoText to flake. It will probably be called
> KoPostscriptPaintDevice

Yes, the problem is that the X dpi setting is applicated twice: once from 
QPainter's conversion from the paint device independent size (points) to the 
device dependent (pixels) and once from QPainter's scale() method, which 
takes its factors from the KoZoomHandler, which in turn takes X's dpi into 
account again. (I think, that was also the reason for the lot of 
doc-view-conversions I removed once. :( )
I tried to invert the latter. That's what I called 'renormalisation' of the 
font size.
But your idea with a special paint device instead of a widget seems to be the 
more cleaner solution. :)

> Hope that helps.

Yip. :)

Stefan

[Attachment #5 (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]