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

List:       koffice-devel
Subject:    Re: Vector format/metafile for KOffice (Re: [Karbon14] misc)
From:       Vadim Plessky <lucy-ples () mtu-net ! ru>
Date:       2002-10-31 7:56:42
[Download RAW message or body]

On Wednesday 30 October 2002 10:27 pm, Dirk Schönberger wrote:
|
|  > I think you missed my point again.
|  > I was speaking about hermite splines as *replacemnt* (or *add-on*) to
|  bezier
|  > splines.
|  > You can control Tension and Continuity with Hermite Splines.
|  > And you can't control those with Bezier splines.
|
|  I think this is utopical. Font creation is done via custom font editing
|  tools, and I don't think that these tools are to be changed to support yet
|  another font format.

And what do you think, *how* I develop my fonts? Using KWrite and T1asm? :-)
You may want to check PfaEdit (http://pfaedit.sourceforge.net)
It's open-source font editor, which supports enermous number of font formats 
(incl. OpenType, which is not supported by Qt3, BTW)

|  And bezier splines are standard tools for most better graphics
| applications, I can't
|  say I know about Hermite splines. So inspite of technical superiority, I
|  think the bezier spline based fonts are the current way.

And MS Windows is *standard desktop* on 95% of all computers.
So, why do you waste your time with KOffice?

[...]
|  > And latest version of that interpreter, called AFPL GS, is not available
|  for free.
|  > GNU counterpart appears about 1.5 years later (1.5 yars *after* release
|  > of AFPL GS)
|
|  Currently I work with something like GS 5.5. The more modern Ghostscripts
|  try to implement the PDF rendering model, the original Postscript
| rendering model is more or less complete, I think.

GS 5.5 *sucks*, believe me!
The lowest version you want to have is GS 6.53, but I highly recommned ESP GS 
7.05.
So, if you are working on GS 5.5 code - you are wasting your time, IMO.
GS 5.5 is about 4 years old.

|  > |  - the actual rendering system
|  >
|  >  libart of ImageMagick?
|
|  I don't think Ghostscript want to limit themselves to the portability of
|  libart or ImageMagick. Besides, still the problem that these libs didn't
|  exist, if development started.

libart was started by Raph, one of key GS developers ;-)
Re: "still the problem that these libs didn't  exist when development started"

Pretty much correct. And that's why GS is so ugly nowdays.
It needs major rewrite. And none of Artifex/ArtOfCode needs rewrite, as they 
can sell existing GS to embedded markets (that's they job/top priority)
They do not care about Linux, Linux Desktop, KDE/GNOME, etc.

|
|  > |  - a small toolkit for achieving multi-platform ability
|  >
|  >  pardon?
|
|  Something like a build system (Makefile), which works on ancient versions
| of VMS or DOS... And some library, which implements standard libc
| functions, which weren't as standard in the old days.

do you care about VMS or DOS?
I think *Linux is enough*. *BSD  is also ok. Why you would care about anythig 
else? (unless port to thos eplatforms doesn't hurt?)

|  > | full level interpreter with its runtime.
|  >
|  > I fit works - great. But so far, I have mixed results with PS import.
|  > Just try to print one page from KWord and import PS files into Karbon.
|  > It doesn't work!
|
|  I haven't checked to re-import exported files into Karbon, but will have
| to do this.
|  Beside, I am not sure about the way QPainter handles text. My own tests
| with re-using QPainter generated text documents were sub optimal. Somehow
| it looked as if the text was rendered to bitmaps and re-vectorized.

Really?..

|  >
|  > I think a whole Java thing is bad.
|  > Idea is great, implementation uscks.
|
|  Hey, I am a professional Java programmer ;)

And I am not :-)

|  >
|  > And KSVG is tied to both Qt and kdelibs, which make sit absolutely
|  unusable
|  > even in GTK apps. So what?
|
|  KSVG provides more than pure rendering of SVG documents, I think. With SVG
|  it should be possible to do animations and scriptin, similar to, say,
| Flash. I don't think this would be possible to implement using rsvg for
| pure rendering (I played around with that idea for myself, too)
|  For scripting and animation you need access to the full SVG DOM, which
| isn't possible if you call some opaque rendering API like rsvg.

I think that by th etime KSVG would be complete (for sttaic ontent), and 
fully-scriptable (for dynamic content), KHTML will show its age ;-))
So, there is no point trying to keep compatibility for the future, if this 
would require major rewrite anyway.

Let's get static rendering first, than think about dynamic features.

|  >
|  > Karbon is very promising.  :-)
|  > What about to use Karbon as KPArt in Konq?
|
|  IMHO Karbon provides a editing KPart for KOffice. An editing KPart is also
|  possible for viewing in Konqueror, or so I think. Perhaps some missing
|  .desktop file?

Don't know. Thi sjust doesn't wok in such way in KO-1.2 and KDE 3.1-beta2

|
|  > What do we need for that?  Move VPainter/Karbon libs into kdelibs?
|
|  I think it suffices to have KOffice installed.

But this doesn't solve problem for Konq.

|
|  > |  Pango provides Unicode rendering for the more exotic languages, think
|  > |  Japanes, Indic, Chinese, Korean. I think a similar functionality is
|  > |  somewhere hidden in Qt3's QPainter and QString. As usual, it is not
|  > | useable without the rest of QPainter.
|  >
|  > I am curious: does KSVG support Japanes, Indic, Chinese, Korean?
|  > If not - there is nothing to discuss here.
|
|  I am not quite sure, but I don't think so.
|  But I am also not quite sure about how difficult it is to use Pango. I
|  believe that this lib creates a glib dependency.

The Right Way id to fix Qt3 and KSVG (if they don't support thos elanguages)
But if KSVG doesn't suppoirt those languages at a moment - you can #ifdef some 
parts of code in librsvg, and compile it without Pango. This would cut off 
Pango/glib dependency.

|  > | KDE. The rendering part is more difficult. There exist multiple
|  > | attempts to
|  > | solve the same problem, including gnome-print. All these attemps have
|  > | a rather different API with different scopes. OTOH most of them
|  > | earlier or later render to libart ;)
|  >
|  > Except ImageMagick ;-))
|
|  I don't know much about ImageMagicks rendering system, I must confess ;)

It the only system/library which support 16-bit per pixel component, and even 
32-bit per pixel component (since Aud.2002) quantum depth.
So, you can convert/transform 48-bit RGB (64-bit RGBA) images with help of 
ImageMagick.
And AA-renderer inside IM would produce 48-bit RGB images, too (out of WMF or 
SVG files)
GS, GNOME2/GTK2, Qt3/KDE3 are limited to 8-bit per pixel (32-bit RGBA), AFAIK.

|
|  Regards
|  Dirk
|  _______________________________________________
|  koffice-devel mailing list
|  koffice-devel@mail.kde.org
|  http://mail.kde.org/mailman/listinfo/koffice-devel

-- 

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
KDE mini-Themes
http://kde2.newmail.ru/themes/

_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]