Expert fonts - are there known problems??
Hi All, I've converted some Mac fonts with t1unmac from the t1utils package to the endianness of my x86 PC, and am seeing strange behaviour in the GIMP. Basically some do and some don't work. In particular one font which has expert features like hanging numbers and small caps etc. completely crashes GIMP - it simply disappears with out a trace. No debug monitor - nothing. I'm going to do some more tests with this font today, in StarOffice and maybe blender, but maybe someone has seen this behaviour too?? The font is Utopya, it's a real adobe release and not some cheap shareware rip-off effort. Other fonts of equal pedigree convert flawlessly. any pointers?? kind regards, avi bercovich -- Avi Bercovich [EMAIL PROTECTED] Sinjeur Semeynsstraat 9 Dept. of Social Science Informatics (SWI) 1183LD Amstelveen University of Amsterdam
Re: TODO for 1.2 release
Nick Lamb wrote: Enough hilarity. If you know of something which must be done before 1.2.0 please follow on to this mail. If you know of a reason why we should unfreeze Gimp instead, feel free to let loose. 1. VAGUE: Documentation should be "good" (definition anyone?) 2. Critical/ Severe bug reports should be fixed or marked down (bug #s?) 3. VAGUE: Gimp should build out-of-box on lots of systems 99. Find and #ifdef any debug scribble to console 100. Check package files, READMEs, etc. for correctness ??. sigaction/OSF/1/GTK resolution Signal messiness. and a temporary hack is (Am I correct on this, Tim Mooney?) is keeping #2742/#6050) at bay for a class of OSF/1 users. The real cause for the bug is in OSF/1, identified by Austin Donnelly, (See bug report for a lot of silly details), http://bugs.gnome.org/db/27/2742.html but GTK didn't respond well to the OSF/1 strangeness and Mitch Natterer had to write temporary error catching code to get plug-ins to correctly identify themselves. I think the conclusion was to revert the temporary patch before 1.2 release. This depends on g_io_channels revisions being injected into a general GTK release, an effort Tim Janik said the GTK team is undertaking. (discussed at Gimp developer's conference, last June). Be good, be well Garry
Re: TODO for 1.2 release
On Monday, 25 Sep 2000, Nick Lamb wrote: 1. VAGUE: Documentation should be "good" (definition anyone?) 2. Critical/ Severe bug reports should be fixed or marked down (bug #s?) 3. VAGUE: Gimp should build out-of-box on lots of systems 99. Find and #ifdef any debug scribble to console 100. Check package files, READMEs, etc. for correctness I agree. In the lists below, I ignore all build problems. There should probably be a separate list of bugs relating to build problems (there seem to be quite a few). I have also skipped over some bug reports to do with plugins. In order of seriousness: A: The gimp core 1) Bugs that cause the main gimp process to crash, or make it impossible to save your work: release CRITICAL. #21269 Bus Error when using paint brush #12582 Crash when 'progressive' selected in jpeg save #12263 Going to "Save As" causes segfault #8150 gimp crashes when loading an invalid brush (which is easy to create) #5878 Xsetpointer change crashes GIMP 2) Correctness problems with main gimp process: GRAVE/CRITICAL. #25272 The thumbnails (.xvpics) do not always match the image. #25266 Load,Crop, then Save results in original (not cropped) image being saved #23601 stand-alone nav window doesn't update on layer info changes #19285 Convolver tool won't operate within 2 pixels of image edge #18913 Brush scaling problems with Size option (pen tablet) #13229 "Magic wand" selects whole image when it's fully zoomed in on. #12754 Crop From Selection, doesn't quite. #10125 "quick" colour picker does not honour "sample merged" #8141 leftover images #7829 merging a layer in dissolve mode makes the layer to look like it was "normal" #6901 Can not continually move a floating selection with a pressure sensitive pointer. #6050 ** WARNING **: wire_read: error for all the plug-ins #5745 module unload needs to be from gtk idle loop #5560 layer dialog disturbing scripts? 3) Problems with presentation: incorrect image refreshes, tool xor dust, and other cosmetic problems: GRAVE. #17904 rounding error in calculation of selection boundary == #22375 GIMP leaves strange (ugly) lines when moving a selection. #21936 Cursor position window doesn't expand after undo #17906 layer move mouse handling not pixel-perfect #16583 "new view" not being updated correctly #10554 Large .jpg not scaled on open #10498 Marching Ants die untimely deaths 4) *** GTK/GDK etc warnings: GRAVE. Most of these arise from failed assertions, and are an indication of some deeper problem. Just because the system stays up doesn't mean it will continue behaving correctly. #22567 window size confused after un-doing resize #15546 some text display problems on HP-UX 5) everything else: NORMAL. B: Plugins -- For plugins, I think we need to take some tough decisions as to which plugins are supported, and which aren't. I don't know how to do this, but others have suggested looking at which are mentioned in the MAINTAINERS file. Once we've decided a plugin is supported, this should mean: 1) All known segfault bugs fixed. #8139 gimpressionist segfaults #7437 Gimpressions crashes 2) Correct, expected behaviour, on all image types. #25968 NL Filter gives strange effects when using alpha 0.5 #25963 Undo of "value invert" on indexed PNG is impossible #12299 NL Filter: shift by one pixel #11828 GIF load fails #10679 Some Scripts mess up the layer stack (Xach Vision) #9156 bug in ifscompose For unmaintained plugins, it depends how much they're used. I suggest running an "adopt a plugin" programme, where people are encouraged to become a plugin "owner", thereby accepting responsibility for its correctness. They should be encouraged to take pride in their plugin. If someone cares about a particular plugin, they will maintain it, otherwise it dies: very Darwinian :) C: Script-fu, perl-fu etc - Check all scripts do something plausible. Hopefully the same as they did under gimp 1.0.4. Maybe this should get a higher priority, but I've never really cared much for the script-fus, and I've never been able to get the perl stuff to work, so I just --disable-perl these days. It may be that some of the bugs I mention above don't exist anymore, or are not reproducible. They should be followed up and eventually closed if the originator can't reproduce them either, or if there's a ChangeLog entry that claims to fix the bug. I'll change the priority of the bugs as I mentioned above. Austin
Re: TODO for 1.2 release
Austin Donnelly wrote: snipped... an extremely useful list. Thank you for composing it B: Plugins -- For plugins, I think we need to take some tough decisions as to which plugins are supported, and which aren't. I don't know how to do this, but others have suggested looking at which are mentioned in the MAINTAINERS file. I would penalize all plug-ins without maintainers 2 points. PLUGIN_MAINTAINERS is the authority on this. I would further penalize all plug-ins with outstanding bug reports a further 1 point per report. The entries in the top half of the list are publically announced as being dropped for 1.2 unless a maintainer comes forward, or the current maintainer addresses outstanding issues, or turns the reins over to someone who can. That instigates a probationary period that lasts until Yosh decides to do the Official 1,2 build. Plug-ins that are still in trouble at that juncture are retired in a 'very Darwinian' fashion. Rolling scoring, in case an orderly plug-in suddenly rebels, and no one know how or cares enough to fix it. The policy is indifferent to manner of implementation. To the end user, script can be just as broken as compiled code. My two U. S. cents. Garry
Re: TODO for 1.2 release
I need to squeeze a little time out of my currently hectic schedule to go back and finish proofreading the help docs. I now have CVS access so I just need to find time and learn how to use CVS and it won't be bad on my part. (if anyone cares about docs that is) bex ps--i know i havent been on IRC lately, but i still read the list and my email.
Re: TODO for 1.2 release
In regard to: Re: TODO for 1.2 release, Garry R. Osgood said (at 5:38am on...: Nick Lamb wrote: Enough hilarity. If you know of something which must be done before 1.2.0 please follow on to this mail. If you know of a reason why we should unfreeze Gimp instead, feel free to let loose. 1. VAGUE: Documentation should be "good" (definition anyone?) 2. Critical/ Severe bug reports should be fixed or marked down (bug #s?) 3. VAGUE: Gimp should build out-of-box on lots of systems 99. Find and #ifdef any debug scribble to console 100. Check package files, READMEs, etc. for correctness ??. sigaction/OSF/1/GTK resolution Signal messiness. and a temporary hack is (Am I correct on this, Tim Mooney?) I was going to send something to the list about this very issue. You are correct. The resolution was to get plumbing in glib so that it detects EINTR and returns some distinguishable error in that case for g_io_channels(). That plumbing hasn't shown up yet. I'll send along what I've composed so far... Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J1, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164
Re: TODO for 1.2 release
In regard to: TODO for 1.2 release, Nick Lamb said (at 8:21pm on Sep 25, 2000): Now, I bet a lot of money that Gimp 1.2 wouldn't be released in 2000 To make me lose, I still remember the announcement for the pre-1.0 party, where S uttered the famous words, "One-point-Oh is close". 21 test releases later, it was. :-) Those guys needed an excuse to unwind, though, so it was still a great idea. I never did hear if Quartic salsa'ed with Beavis the cat, though... 1. VAGUE: Documentation should be "good" (definition anyone?) 2. Critical/ Severe bug reports should be fixed or marked down (bug #s?) 3. VAGUE: Gimp should build out-of-box on lots of systems 99. Find and #ifdef any debug scribble to console 100. Check package files, READMEs, etc. for correctness A problem (#2742/#6050) that Garry Osgood, Austin Donnelly, and Mitch Natterer worked on that's related to fubar handling of SA_RESTART on alpha-dec-osf boxes was (in theory) going to be fixed by getting some special plumbing in glib's g_io_channel(), so that gimp didn't have to rely on SA_RESTART. Austin has a quote from Tim Janik that adding the necessary stuff would be fairly easy to do. So far there hasn't been a 1.2.9 of glib that adds the plumbing, but glib/gtk+ is probably harder to get new stuff into right now than gimp is, because of where they are in their release cycle. I can't get the text from any of the bugs in the database right now, but #15546 makes gimp pretty much unuseable on HP-UX. The next two are build problems -- Austin is right that they should probably be handled separately, but they are (IMHO) still important. As I've reported previously on this list, because of build problems prevalent in gtk+ and gimp, both are unuseable on AIX. The problem is really in libtool's poor support for AIX's goofy shared object requirements, but unless someone documents it in a README, gimp users on AIX are going to be disappointed. I'll try build 1.1.26 or some subsequent release on the platforms I have access to, but whoever does pre-release builds (Yosh?) should see if there's a way to make your compiler (gcc?) warn/error on C++ style comments. Every single point build of gimp for the last dozen or so builds has included new C++ style comments in various places, and invariably that's going to cause problems on some platform. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J1, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164
Re: TODO for 1.2 release
On 26 Sep, Tim Mooney wrote: Grepped through the source and couldn't find any C++ style comments... cc: Error: lighting_ui.c, line 387: Invalid statement. (badstmt) // GtkWidget *spinbutton; --^ This is from 1.1.26/plug-ins/Lighting. I haven't made the build proceed any farther, to see if there are others. Perhaps it's been fixed in CVS already, and that's what you're looking at? No, it's not fixed in CVS but for some reason find -name *.c | grep "//" - didn't work as I would have expected it. Will grep it manually and replace every C++ comment by a C comment. Thanks for pointing out! -- Servus, Daniel
Re: TODO for 1.2 release
In regard to: Re: TODO for 1.2 release, [EMAIL PROTECTED] said (at 12:19am on...:
Perhaps it's been fixed in CVS already, and that's what you're looking
at?
No, it's not fixed in CVS but for some reason
find -name *.c | grep "//" -
You need to quote the '*.c', it's getting expanded by the shell before
it ever gets fed to find. :-)
find . -name '*.c' -exec egrep '//' {} /dev/null \;
or
find . -name \*.c -exec egrep '//' {} /dev/null \;
Better:
find . -name '*.c' -o -name '*.h' -exec egrep '//' {} /dev/null \; | \
grep -v '://'
(to get rid of false matches on URLs)
didn't work as I would have expected it. Will grep it manually and
replace every C++ comment by a C comment. Thanks for pointing out!
You're welcome!
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J1, IACC Building (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
Re: TODO for 1.2 release
On 26 Sep, Tim Mooney wrote: You need to quote the '*.c', it's getting expanded by the shell before it ever gets fed to find. :-) Actually that's not the problem since there are no *.c files in the directory I started the search in... Anita:/mnt2/src/gimp # find -name *.c ./libgimp/gimpsignal.c ./libgimp/gimpwidgets.c ./libgimp/gimpchannel.c ./libgimp/gimpexport.c ./libgimp/gimpbrushselect_pdb.c ./libgimp/gimplayer_pdb.c ... That's not the problem. For some reason the grep failed :/ -- Servus, Daniel
Re: TODO for 1.2 release
On Tuesday, 26 Sep 2000, Tim Mooney wrote: @@ -2322,6 +2322,7 @@ G_IO_ERROR_NONE, G_IO_ERROR_AGAIN, G_IO_ERROR_INVAL, + G_IO_ERROR_INTR, G_IO_ERROR_UNKNOWN } GIOError; This breaks backwards binary compatibility, since the numeric value of G_IO_ERROR_UNKNOWN changes. I agree it looks nicer, though. See my (very similar) patch attached to the end of this email, which doesn't have this problem. It builds and works correctly in (very) light testing on gimp 1.1.23 and glib 1.2.8 Tor, are there similar changes needed to giowin32.c ? Austin eintr-patch
Re: TODO for 1.2 release
In regard to: Re: TODO for 1.2 release, Austin Donnelly said (at 11:35pm on...: On Tuesday, 26 Sep 2000, Tim Mooney wrote: @@ -2322,6 +2322,7 @@ G_IO_ERROR_NONE, G_IO_ERROR_AGAIN, G_IO_ERROR_INVAL, + G_IO_ERROR_INTR, G_IO_ERROR_UNKNOWN } GIOError; This breaks backwards binary compatibility, since the numeric value of G_IO_ERROR_UNKNOWN changes. I agree it looks nicer, though. :-) Looks aren't everything. I thought about inserting the new enum value after UNKNOWN. Your change should be the lowest impact, so you're right that it's the way to go. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J1, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164
Re: TODO for 1.2 release
[EMAIL PROTECTED] wrote:
On 26 Sep, Tim Mooney wrote:
Grepped through the source and couldn't find any C++ style
comments...
cc: Error: lighting_ui.c, line 387: Invalid statement. (badstmt)
// GtkWidget *spinbutton;
--^
There are a number of C++ style comments. I ran the following command
against the GIMP 1.1.26 source which I last updated from the CVS repository
as of sometime last night.
find . -name "*.[ch]" -print -find . -name "*.[ch]" -print -exec grep \/\/
{} \;
(NOTE: Lines starting with ./gimp indicate the name of a file containg C++
comments)
./gimp/app/channel_ops.c
// 64,64,128,128);
//
newgdisplay-disp_width,newgdisplay-disp_height,
//
newgdisplay-disp_width+newgdisplay-disp_xoffset,newgdisplay-disp_height+newgdisplay-disp_yoffset
./gimp/app/convert.c
// boxp-Rhalferror = (Rmin+Rmax)/2;
// boxp-Ghalferror = (Gmin+Gmax)/2;
// boxp-Bhalferror = (Bmin+Bmax)/2;
//R = ((b1-Rmax - b1-Rmin) R_SHIFT) * R_SCALE;
//G = ((b1-Gmax - b1-Gmin) G_SHIFT) * G_SCALE;
//B = ((b1-Bmax - b1-Bmin) B_SHIFT) * B_SCALE;
./gimp/app/tile_manager.c
// fprintf(stderr,"V%p ",tm-user_data);
./gimp/plug-ins/Lighting/lighting_ui.c
// GtkWidget *spinbutton;
./gimp/plug-ins/print/print-weave.c
//putchar('\n');
./gimp/plug-ins/sel2path/spline.c
/* //HB: the above is really nice, but is there any other compiler
./gimp/plug-ins/twain/tw_func.h
#endif // _TW_FUNC_H
./gimp/plug-ins/twain/tw_util.h
#endif // __TW_UTIL_H
./gimp/plug-ins/twain/twain.h
#ifdef __BORLANDC__ //(Mentor June 13, 1996) if using a Borland
compiler
#pragma option -a2 //(Mentor June 13, 1996) switch to word
alignment
#else //(Mentor June 13, 1996) if we're using some other compiler
#endif //(Mentor June 13, 1996)
// TW_MEMREF pData; /* Based on implementation specifics, a
*/
// TW_MEMREF pData; /* Based on implementation specifics, a
*/
//#define TWSS_B 8
#ifdef __BORLANDC__ //(Mentor June 13, 1996) if we're using a Borland
compiler
#pragma option -a. //(Mentor October 30, 1996) switch back to
original alignment
#else //(Mentor June 13, 1996) if NOT using a Borland compiler
#endif //(Mentor June 13, 1996)
./gimp/plug-ins/winsnap/resource.h
//{{NO_DEPENDENCIES}}
// Microsoft Developer Studio generated include file.
// Used by snappy.rc
//
// Next default values for new objects
//
./gimp/plug-ins/winsnap/winsnap.c
/* //HB: update data BEFORE size change */
Cheers!
Kevin. (http://www.interlog.com/~kcozens/)
Internet:kcozens at interlog.com |"What are we going to do today, Borg?"
or:ve3syb at rac.ca |"Same thing we always do, Pinkutus:
Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!"
#include disclaimer/favourite| -Pinkutus the Borg
Re: TODO for 1.2 release
"Moses P. Milazzo" wrote: Why not: grep "//" `find . -name "*.[ch]"` | grep -v 'p://' You should include -print as part of the find statement or else you will wind up getting a list of lines containing C++ style comments without knowing the name of the file that needs to be edited. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
Re: TODO for 1.2 release
In regard to: Re: TODO for 1.2 release, Moses P. Milazzo said (at 4:28pm on...:
Better:
find . -name '*.c' -o -name '*.h' -exec egrep '//' {} /dev/null \; | \
grep -v '://'
(to get rid of false matches on URLs)
Why not:
grep "//" `find . -name "*.[ch]"` | grep -v 'p://'
(the -o option doesn't seem to work as advertised in the man page)
Depends on the man page you read, and the platform you're on.
Don't forget that ":" is used between the filename and matching line, and
if your line begins with //, grep -v '://' chucks that valid match.
This is degenerating from the original thread, but you're right that
my grep -v '://' might throw away too much.
I avoid the backticks that you used because in general that could result
in a "line too long" problem, on many UNIXes. My method is slower by a
lot because it will exec egrep for every file in the list, but it will
never fail because of too many files. Probably not an issue in this case,
so yours might be better here but it might fail for a larger tree on
some platforms.
In any case Kevin's find/grep did what was needed -- find the files that
have C++ style comments in them.
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J1, IACC Building (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
