Subject: re: TODO for the next release.
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Thu Jun 14 2001 - 01:53:44 CDT
On Wed, 13 Jun 2001, Dom Lachowicz wrote:
> Hi Martin,
>
> > > 3) Make toolbar color buttons work on win32 and unix-non-gnome
> >
> > I don't mind the gtk-only not having these. If needed, this
> > functionality
> > can be provided via the "font" or "styles" dialog. See my reasoning on
> > gtk-only below. I have no great desire to reinvent wheels for
> > gtk-only. The gnome build is meant to be better than gtk-only anyway
> > since
> > it builds on a great platform of other people's work.
>
> Well, first off, thanks :) Secondly, this is unacceptable. I'll even do the
> code for this. We don't need to make it a drop-down widget. Popping up a
> GtkColorSel inside of a dialog when the button is pressed would suffice, IMHO.
> It'll take me 15 minutes. Win32 guys - connect a callback to the pressed signal
> on the button and do the same.
>
OK this makes sense. A color picker inside a frame is fine by me.
> > > 4) Clipart dialog
> > > - Dom: dload, checkin, and install clipart
> > > - Non-gnome platforms: actually code the dialog
> >
> > Dom, I've looked at your screen shot and thought about doing a GTK-only
> > dialog. Then I realized I would have to essentially rewrite gdk-pixbuf
> > to
> > make each clip art image scale to the right size to fit nicely on the
> > dialog.
> >
> > I have no intention of wasting my time to do this. The gtk-only build is
> > only for users without the diskspace or system requirements for the
> > beautiful gnome build.
> >
> > Given this, the clip-art dialog would default to look eactly like the
> > "insert image" dialog with the only difference being that the file
> > directory defaults to point to a clip-art directory that Abi knows about
> > although I do not yet.
>
> Ok, then disable this. I'm not a big fan of your decision, however. Scaling
> images is easy given our current codebase, and no we wouldn't have to rewrite
> GdkPixbuf to do accomplish this. See the image preview code in the OpenSaveAs
> dialog as an example. Either we:
>
> 1) Code it right
> 2) Disable it altogether for Unix
>
> I won't allow the insert-image dialog to double as the clipart dialog.
>
I didn't realize abi had the ability to scale images. Of course it must
have otherwise zoom wouldn't work. OK I'll look at this more closely. I
should learn more about Abi's image handling anyway so I can take part in
the next great Abiword image debate :-)
>
> I like it both ways, and I think it'll stay this way. It's more convenient to
> do it via a preference for those people who want to turn it off. Of course
> it'll be turned on by default.
>
OK. I just committed a fix to the gtk build for a crash on startup from
this. You accessed pPreps before creating it :-)
> > 14. Make printing work on Unix. I have a document with symbol fonts
> > written by a real user that he cannot print correctly. The gnome-print
> > sucks rocks badly. It screws up pagination and totally barfs on the
> > symbol
> > and dingbat fonts. Our own print prints the symbols and gets the
> > pagination right but throws in some extraneous degree symbols after
> > them!
> > I will work solidly on getting both the abi printing and gnome-print to
> > work correctly. I'll check this document into bugzilla and I think we
> > should not release 0.90 until it prints correctly.
>
> Printing on Unix in general sucks rocks through a garden hose. We really need
> to work on printing in general, because there are XP bugs in there too... I'll
> work on GnomeFont, but I've been told more than once that we don't use the
> correct glyphs for Symbol and Dingbats characters internally, so I'm not
> surprised that the GnomePrint build barfs on them, though it does suck.
>
I just ran some tests. For 12 point Times New Roman Fonts the height of
the postscript font via our postscript generator is 1356. Using
Gnome-Print generated PS this height 1391. This is 2% larger and accounts
for the non-WYSIWYG behaviour from gnome-print.
I suspect that gnome-print is using different fonts. I just looked at the
code in xap_UnixGnomePrintGraphics.cpp and I realized that this is exactly
what is happening. We do a map between AbiWord's fonts and
whatever fonts gnome-print picks up. It is not surprising that we don't
get WYSIWYG from gnome-print.
We must use identical fonts to gnome-print. Either Abi uses whatever fonts
gnome-print has or we force gnome-print to use our fonts. It is the only
way to do this correctly.
I'll keep on this for the next few days Dom. I hope you can find time to
fix the hastable bugs. Editting valid documents causes them to become
bogus upon saving right now.
>
> > 16. We desperately need to split out data from source code. All the help
> > files, template files and spelling hash files should be seperated into a
> > language specific module and downloaded seperately. Maybe we should do
> > this for Fonts as well in the case of CJK fonts. We need to work out a
> > cross platform way of doing this and to reorganize our CVS and build
> > system to reflect this. Any volenteers for this?
>
> Yes, I'm putting this to post 0.9.0 but pre 1.0 unless someone steps up to do
> it. It's something that has to be done. I'm hoping to completely remove the
> current help files and instead introduce the ones that the great folks on
> abiword-docs have been working on instead. They're even in ABW format :-)
>
I agree that this could wait till post 0.90. I'm hoping though that
someone will step up and volenteer to implement this. Sam?
Cheers
Martin
This archive was generated by hypermail 2b25 : Thu Jun 14 2001 - 02:04:06 CDT