From koffice-devel Tue Jan 16 20:58:55 2007 From: Stefan Nikolaus Date: Tue, 16 Jan 2007 20:58:55 +0000 To: koffice-devel Subject: Re: Extra font scaling? (Re: koffice/kspread) Message-Id: <200701162200.32937.stefan.nikolaus () kdemail ! net> X-MARC-Message: https://marc.info/?l=koffice-devel&m=116898113502470 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============1984039432==" --===============1984039432== Content-Type: multipart/signed; boundary="nextPart1281805.4gd5KeXMXr"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1281805.4gd5KeXMXr Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 docume= nt > 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 fontsi= ze > 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 adju= st > 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 bas= ed > 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= =20 dpi value of about 72? Then you'd get a factor of ~1.0, that's used for=20 QPainter::scale. The more deviation from 72 the worse. > > The printing indeed would cause problems with renormalizing the font si= ze > > 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_ y= ou > 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.=20 > > > 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=20 QPainter's conversion from the paint device independent size (points) to th= e=20 device dependent (pixels) and once from QPainter's scale() method, which=20 takes its factors from the KoZoomHandler, which in turn takes X's dpi into= =20 account again. (I think, that was also the reason for the lot of=20 doc-view-conversions I removed once. :( ) I tried to invert the latter. That's what I called 'renormalisation' of the= =20 font size. But your idea with a special paint device instead of a widget seems to be t= he=20 more cleaner solution. :) > Hope that helps. Yip. :) Stefan --nextPart1281805.4gd5KeXMXr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFrTzwpfDn2DABIpcRAu6wAKCp0mRSMoYzqcFxcJx9NGfBDT0D8QCgzUA4 GimU0j1g4/Szx3+4EJTDNz0= =PXtS -----END PGP SIGNATURE----- --nextPart1281805.4gd5KeXMXr-- --===============1984039432== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ koffice-devel mailing list koffice-devel@kde.org https://mail.kde.org/mailman/listinfo/koffice-devel --===============1984039432==--