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

List:       koffice-devel
Subject:    Re: Extra font scaling? (Re: koffice/kspread)
From:       Thomas Zander <zander () kde ! org>
Date:       2007-01-16 20:01:47
Message-ID: 200701162101.48562.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 16 January 2007 17:10, Stefan Nikolaus wrote:
> On Sunday, January 14, 2007 07:30:07 PM Thomas Zander wrote:
> > If you use the KoZoomHandler this implies that you made your content (the
> > sheet) a specific size in a real unit. Which implies that what you want
> > is incompatible with the goals of flake.
> >
> > After all, if I insert said sheet in a kword doc at 10x10 cm. I want it
> > to be 10x10 cm.  DPI be damned.  Considering you don't need to change the
> > flke when printing, think about what would happen if you print on a
> > 600DPI printer for example ;)
>
> Okay, actually it's not a flake specific problem (yet), but its cause is
> the same: QPainter::scale() in conjunction with KoZoomHandler.

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.

> 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.

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.

> 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 ;)

> > 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

Hope that helps.

Cheers!
-- 
Thomas Zander

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