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
