[Kde-graphics-devel] http://bugs.kde.org/show_bug.cgi?id=100284

[Marcel Partap]

Well, as this might be a good place to bring this up, I'm doing.
So... comments, please?
regards.

[Marcel Partap]

was:
Re: [Kde-graphics-devel] http://bugs.kde.org/show_bug.cgi?id=100284was
> So... comments, please?
Everybody has remained silence so I wondered if it was because of the
nondescriptive subject of my first post...or.. ?
Everything i came up with is in that wish report, does anyone have an
idea about implementing this? How does KPDF show the fonts? What about
performance (smooth scaling?? GL?) ? And most important, do you consider
it a good idea? I for one think that it improves the usability if
webpages behave more like real paper documents (which don't rerender if
you look closer), but what do you other guys think?
</spawn_discussion>
regards, and thx everyone for a really, really great 3.4 ;D
(world domination just got closer... one day, open source will rule the
world! ;)

On Tuesday 01 March 2005 10:48, Marcel Partap wrote:
> was:
> Re: [Kde-graphics-devel] http://bugs.kde.org/show_bug.cgi?id=100284was
>
> > So... comments, please?
>
> Everybody has remained silence so I wondered if it was because of the
> nondescriptive subject of my first post...or.. ?

it may be that to answer this it requires a good knowledge of the internals of
khtml, and given that as a base line some time to sit down and think of the
ramifications. html rendering is woefully complex, and so doing such a thing
may not be so trivial. so .. if there aren't any khtml experts on this list
with the time to consider what it would mean, then ... yeah... i wouldn't
expect an answer right away =)

--
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-graphics-devel/attachments/20050301/c2339191/attachment.pgp

[Marcel Partap]

Aaron J. Seigo wrote:
> with the time to consider what it would mean, then ... yeah... i wouldn't
> expect an answer right away =)
BUT I WANT IT I WANT IT ***NOW*** SO ARE YOU TELLING ME I DONT DESERVE
IT??? IF THATS SO LET ME SAY WHAT I THINK I THINK kde DOESNT DESERVE
*me* AS A USER AND IT SUX ANYWAYS!! YOU'LL *never* GET AS GOOD AS
WONDIWS!!! SCREW YOU GUYS - i'M GOOOOING HOME... YOU GO RIGHT WHERE YOU
WANT TO OR I'LL SHOVE IT UP YO....
</trollflash>
wooaw, hey now what was that. sorry. I tripped :D
Yes I guess that is Open Source too, you cannot force people to discuss *g
Err, yeah anyways, let's just assume until refuted it IS technically
possible, what do you think about the idea? Ohhh comeooon Aaron, now
that you replied - you're in.
rgrns

On Tuesday 01 March 2005 01:07, Marcel Partap wrote:
> </trollflash>

lol ... =)

> Err, yeah anyways, let's just assume until refuted it IS technically
> possible, what do you think about the idea? Ohhh comeooon Aaron, now
> that you replied - you're in.

heh.. i would but i don't know khtml's internals at all and am too busy right
now to spend the time learning them .. sorry =)

--
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-graphics-devel/attachments/20050301/6d41dc76/attachment.pgp

[Dirk Schönberger]

> Everything i came up with is in that wish report, does anyone have an
> idea about implementing this? How does KPDF show the fonts?

I think the basic difference between PDF / KPDF and HTML / KHTML is that the
former is page based
while the other is "flow" based. If your document has a fixed page size,
i.e. e.g. "A4" in "logical" coordinates, you can scale
all other elements (graphic elements, text, images) in relation to this base
size. I.E. you scale the whole page with 120%.

KPDF / XPF uses this design and AFAIK it implements its own render engine,
based on the Postscript rendering model, where
each graphical element about to displayed is applied to a global
transformation matrix. Another implementation of this idea is the Qt4
rendering engine (Arthur).

By contrast, KHTML uses the normal Qt level QPainter, which uses a more
simple model based on non-scaled pixels (and displayed areas).
In this model you have to explicit scale each graphical element by itself,
which can lead to layout changes (graphical elments and images may contain
scaling errors, or they may be displayed suboptimal because of scaling
problems. For text output  you have to use scaled fonts (i.e. instead of
rendering a 16pt font at 125 percent you ask Qt for a font of 20pts. Scaled
fonts hae different font metrics, i.e. they scale not linearly.

> What about performance (smooth scaling?? GL?) ? And most important, do you
consider
> it a good idea? I for one think that it improves the usability if
> webpages behave more like real paper documents (which don't rerender if
> you look closer), but what do you other guys think?

I don't really think its a good idea. HTML was never designed to be a page
oriented medium, so most of the existing HTML documents don't assume this.
However, they assume to have a fixed pixel based window width or base
height, e.g. for naigation bars. This doesn'?t mix well with a page based /
Postscript like approach.

Regards
Dirk

[Michael Dean-4]

Well there has to be a good way to do it.  Just look at Opera.  I have
wanted this feature for awhile myself, since I use two screen
resolutions: 1600x1200 and 1920x1440.    My screen resolution combined
with this extension for Firefox are why I use Firefox a lot more than
I'd like to.

I really don't think this is a graphics issue, though.  You can't just
scale the entire image because the fonts will get jagged.  The font
scaling has to be the hardest part to get right, as (like Dirk said)
font point sizes are nonlinear.  A nice addition for the meantime
might be the ability to zoom images, as the extension for Firefox
ImageZoom will do.
 
But where there's a will there's a way, and we all know that Opera has
been able to do this for years.  I just wish I knew enough about html
rendering to help.

On Tue, 01 Mar 2005 18:48:06 +0100, Marcel Partap <mpartap@...> wrote:

> was:
> Re: [Kde-graphics-devel] http://bugs.kde.org/show_bug.cgi?id=100284was 
> > So... comments, please?
> Everybody has remained silence so I wondered if it was because of the
> nondescriptive subject of my first post...or.. ?
> Everything i came up with is in that wish report, does anyone have an
> idea about implementing this? How does KPDF show the fonts? What about
> performance (smooth scaling?? GL?) ? And most important, do you consider
> it a good idea? I for one think that it improves the usability if
> webpages behave more like real paper documents (which don't rerender if
> you look closer), but what do you other guys think?
> </spawn_discussion>
> regards, and thx everyone for a really, really great 3.4 ;D
> (world domination just got closer... one day, open source will rule the
> world! ;)
> _______________________________________________
> Kde-graphics-devel mailing list
> Kde-graphics-devel@...
> https://mail.kde.org/mailman/listinfo/kde-graphics-devel 
>

[Luke-Jr]

On Tuesday 01 March 2005 22:20, Dirk Sch?nberger wrote:
> > I for one think that it improves the usability if webpages behave more
> > like real paper documents (which don't rerender if you look closer),
> > but what do you other guys think?
>
> I don't really think its a good idea. HTML was never designed to be a page
> oriented medium, so most of the existing HTML documents don't assume this.

However, CSS makes [X]HTML very usable for print output. I now do all my
printed work using CSS/XHTML and the only problems I have had thus far is
lack of full CSS support in browsers (I generally stick to KHTML since it has
the best of all the implementations)

> However, they assume to have a fixed pixel based window width or base
> height, e.g. for naigation bars.

This is a problem in itself. Webpages that won't work with any arbitrary width
(over 640x480) have issues... And before someone says nobody uses 640x480
anymore, consider that not everyone has their browsers maximized.

> This doesn'?t mix well with a page based / Postscript like approach.

Nor with screen-based display.
--
Luke-Jr
Developer, Utopios
http://utopios.org/

[Matías Costa]

El Martes 01 Marzo 2005 19:13, Aaron J. Seigo escribi?:

> On Tuesday 01 March 2005 10:48, Marcel Partap wrote:
> > was:
> > Re: [Kde-graphics-devel] http://bugs.kde.org/show_bug.cgi?id=100284was
> >
> > > So... comments, please?
> >
> > Everybody has remained silence so I wondered if it was because of the
> > nondescriptive subject of my first post...or.. ?
>
> it may be that to answer this it requires a good knowledge of the internals
> of khtml, and given that as a base line some time to sit down and think of
> the ramifications. html rendering is woefully complex, and so doing such a
> thing may not be so trivial. so .. if there aren't any khtml experts on
> this list with the time to consider what it would mean, then ... yeah... i
> wouldn't expect an answer right away =)

I do not know khtml internals, but it provides a DOM interface. I am going to
try to make a plugin witch walks the three scaling width / height / size
attributes. Sure I will don't get anything usable but it will be fun.

[Marcel Partap]

> transformation matrix. Another implementation of this idea is the Qt4
> rendering engine (Arthur).
Which is good :)

> By contrast, KHTML uses the normal Qt level QPainter
can this be changed?
> [...]
> scaling errors, or they may be displayed suboptimal because of scaling
> problems. For text output  you have to use scaled fonts (i.e. instead of
> rendering a 16pt font at 125 percent you ask Qt for a font of 20pts. Scaled
> fonts hae different font metrics, i.e. they scale not linearly.
Yeah, that's the problem we have right now, minus image scaling.

> I don't really think its a good idea. HTML was never designed to be a page
> oriented medium, so most of the existing HTML documents don't assume this.
They don't have to.
> However, they assume to have a fixed pixel based window width or base
> height, e.g. for naigation bars. This doesn'?t mix well with a page based /
> Postscript like approach.
I don't think much has to change. The renderer would render the page
just like now at the default font size 100%, then display it PS-like
(with Arthur?). How and if exactly - sorry, I have no clue about the
KHTML interna, except that they work and rock (fast!).

Besides technical feasibility: what do you folk say about usability? Are
there any disadvantages?

Thank you very much Dirk for your resonse :D

On Wednesday 02 March 2005 11:39, Marcel Partap wrote:
> I don't think much has to change. The renderer would render the page
> just like now at the default font size 100%, then display it PS-like
> (with Arthur?). How and if exactly - sorry, I have no clue about the
> KHTML interna, except that they work and rock (fast!).

No, a lot would have to change to be able to do that.

> Besides technical feasibility: what do you folk say about usability?
> Are there any disadvantages?

It's something probably every khtml thought about for many years. The
reason no one even bothered with it is that no one thought that it'd be
worth doing at this point. I don't see really any case where this would
be a killer feature. It's a nice thing, sure, but nothing you couldn't
live without. And considering that it is something that would be very
hard to implement properly in khtml I don't think anyone will bother.

Especially that in the coming months all apps will get that for free
(you could do it today, by rendering the window as a texture on a quad
in GL but you'd still have to transform and map input events
correctly).

Zack

--
PCMCIA - People Can't Memorise Computer Industry Acronyms

[Marcel Partap]

Zack Rusin wrote:
 > Especially that in the coming months all apps will get that for free
You mean Arthur?
And why would it be so hard to put the rendered site in a
Ghostscript-like bufferformat and then display? How does KHTML do it now
anyways: does it render only the part of the page that is shown? Does it
render the whole, and where does it put it then? If you scroll, say, to
the end of the page, how is the end displayed?
And even if it was an obvious idea - how come I was first to report it?
I think I'll have a look at Opera and its implementation as soon as I
get this damn

grep: //usr/lib/gcc/i686-pc-linux-gnu/3.4.3/libstdc++.la: No such file
or directory
/bin/sed: can't read //usr/lib/gcc/i686-pc-linux-gnu/3.4.3/libstdc++.la:
No such file or directory
libtool: link: `//usr/lib/gcc/i686-pc-linux-gnu/3.4.3/libstdc++.la' is
not a valid libtool archive
make[2]: *** [kimg_tiff.la] Error 1

thing fixed.
cheers

[Maksim Orlovich-2]

On Wednesday 02 March 2005 12:20, Marcel Partap wrote:

> Zack Rusin wrote:
>  > Especially that in the coming months all apps will get that for free
>
> You mean Arthur?
> And why would it be so hard to put the rendered site in a
> Ghostscript-like bufferformat and then display? How does KHTML do it now
> anyways: does it render only the part of the page that is shown? Does it
> render the whole, and where does it put it then? If you scroll, say, to
> the end of the page, how is the end displayed?
> And even if it was an obvious idea - how come I was first to report it?

You weren't. You were the first to ask that it extend to kparts and not just
images.

[Marcel Partap]

Zack Rusin wrote:
> No, a lot would have to change to be able to do that.
Oh nooooow I see...
- ln -s'ed /usr/lib/gcc/i686-pc-linux-gnu/3.4.3 3.4.3-20050110;
- installed opera (hey damn it's qquite good! even that kinda WFW3.11
feeling is gone.. )
- had a look at it's zooming implementation => obviously just
additionaly uses img tranformatrices in comparison to konqi
=>
When I saw what it's doing I recognised the problem of my idea: page
boundaries. You preferably want to have your browser display the full
width of the page. Now if you show a scaled buffered rendered at 100%
incarnation (like a PDF) - you obviously straight away have to scroll
after zooming in. Didn't quite think of that...
Mhh. So it could be 2 (configurable! ;) ways then:
a) just like now + image scaling (and position grip, see #40277)
b) Document based rendering, with problems like page width and what Zack
mentioned (input transform..)

> be a killer feature. It's a nice thing, sure, but nothing you couldn't
No it's not. But is usre'd look cool to zoom into the page smoothly and
back, like moving your had towards a piece of paper.. I thought KDE is
all about eye-candy? :D

> live without.
NEVER! Alas it happens.
> And considering that it is something that would be very
> hard to implement properly in khtml I don't think anyone will bother.
I know get that..
Any magical solution someone can up with?
regards..

[Marcel Partap]

>>And even if it was an obvious idea - how come I was first to report it?
> You weren't. You were the first to ask that it extend to kparts and not just
> images.
Uh wait did I say that?
Don't think, actually I 'only' wanted a PDF like zooming in KHTML. Who
would have guessed those only-things to have such a weak
cost/performance ratio.
Anyways, what about Arthur? Will it give that automagically to all KParts?

[Friedrich W. H. Kossebau]

Am Mittwoch, 2. M?rz 2005 17:51, schrieb Zack Rusin:
> On Wednesday 02 March 2005 11:39, Marcel Partap wrote:
> > Besides technical feasibility: what do you folk say about usability?
> > Are there any disadvantages?
>
> It's something probably every khtml thought about for many years. The
> reason no one even bothered with it is that no one thought that it'd be
> worth doing at this point. I don't see really any case where this would
> be a killer feature.

Never having done a work presentation on your computer right on your display,
to a bunch of people standing a few meters away? I have wished a lot of times
that all apps could enlarge their content views... Switching to a lower
resolution is one solution, but not my favourite...

> It's a nice thing, sure, but nothing you couldn't
> live without. And considering that it is something that would be very
> hard to implement properly in khtml I don't think anyone will bother.
>
> Especially that in the coming months all apps will get that for free
> (you could do it today, by rendering the window as a texture on a quad
> in GL but you'd still have to transform and map input events
> correctly).

Will they? Will there be independent zooming of the content views, without
enlarging the toolbars and other helper widgets?

Regards
Friedrich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-graphics-devel/attachments/20050302/9f69ebfa/attachment.pgp

[Lars Knoll]

On Wednesday 02 March 2005 20:08, Friedrich W. H. Kossebau wrote:

> Am Mittwoch, 2. M?rz 2005 17:51, schrieb Zack Rusin:
> > On Wednesday 02 March 2005 11:39, Marcel Partap wrote:
> > > Besides technical feasibility: what do you folk say about usability?
> > > Are there any disadvantages?
> >
> > It's something probably every khtml thought about for many years. The
> > reason no one even bothered with it is that no one thought that it'd be
> > worth doing at this point. I don't see really any case where this would
> > be a killer feature.
>
> Never having done a work presentation on your computer right on your
> display, to a bunch of people standing a few meters away? I have wished a
> lot of times that all apps could enlarge their content views... Switching
> to a lower resolution is one solution, but not my favourite...
>
> > It's a nice thing, sure, but nothing you couldn't
> > live without. And considering that it is something that would be very
> > hard to implement properly in khtml I don't think anyone will bother.
> >
> > Especially that in the coming months all apps will get that for free
> > (you could do it today, by rendering the window as a texture on a quad
> > in GL but you'd still have to transform and map input events
> > correctly).
>
> Will they? Will there be independent zooming of the content views, without
> enlarging the toolbars and other helper widgets?

With the recent developments on the X.org side you'll hopefully get zooming of
apps rather soon, but with Qt 4 you'll also get the zooming in widgets.

You's still have to do some work in the view, but once the apps use Qt4, they
will get quite a bit of it for free. The problem with zooming in the painter
is that the results will usually get somewhat blurry, which for an html view
can be a problem. But I guess that's something one could try out.

Cheers,
Lars