Description of problem: #1: Hotkeys are not responded. #2: "Go To" window couldn't be inputted. Version-Release number of selected component (if applicable): fontforge-20080828-1.fc10.i386 How reproducible: Always. Steps to Reproduce: 1. Start fontforge from gnome-terminal. 2. Try hotkeys like Alt-F. 3. Observe symptom #1. 4. Select View > Goto from menu. 5. Try to input something in the input field. 6. Observe symptom #2. Actual results: #1. No response. #2. Couldn't be inputted. Expected results: #1. File sub-menu pops up. #2. Data is inputted in field. Additional info: HEAD of F9 has same issue as well.
`LANG=C fontforge [FILE]` resolves as workaround.
Odd. I can't reproduce this here on f9 or devel. What is your LANG env set to normally? I have en_US.UTF-8 here and it's working fine.
$ echo $LANG en_US.utf8
I can't duplicate this here. ;( Is something stealing your focus? Does it happen in a newly created user?
FYI, according to fontforge contributor, George Willams and Nicolas Spalinger: ----- On Fri, 2008-09-12 at 02:24, Nicolas Spalinger wrote: > > I have spotted 2 possible bugs on fontforge. The hotkeys and inputting to goto window doesn't work, > > except prefix with 'LANG=C' in command line. i.e. `LANG=C fontforge`. > Not sure, but this may have something to do with some problems I've > noticed when using fontforge when a smart input methods (like SCIM/KMFL) > is running. I should be able to give a more useful description soon. As I said, I cannot duplicate the problem, all works fine for me, which makes Nicolas's suggestion likely. As far as I can tell there is nothing funny about the Goto dialog and I can't imagine how input could work other places and not there. I've added some debugging code to the cvs tree so that I can see what the input method does to the input stream. If you are interested could you build fontforge from cvs $ CFLAGS="-g -DTESTXIM" ; export CFLAGS $ ./configure $ make $ su # make install And then run fontforge and tell me what is printed (to stdout) when you try to do the things that don't work.: ----- It might be some conflicts between SCIM and fontforge, as my sys env is SCIM started by default.
Ah, I do not have SCIM enabled here at all... that could be the case. I'm not sure how to fix this here, but perhaps upstream they can come up with a solution and we can use that in fedora.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Caius: Can you confirm it's SCIM causing this issue? Also, can you try the 20081215 version I just built in rawhide? Where should we go from here with this bug?
I've turned SCIM off on F10 and prob still exists. I don't have rawhide on hand atm so need to prep that before triage.
Can you test the latest build in rahide when you have time, Caius?
It worked on my rawhide (F10 + yum update to rawhide), on 22 Dec 2008.
In reply to comment #11. It worked with SCIM? Or without? Or both? :)
(In reply to comment #12) Both. :)
Excellent. I am going to go ahead and close this then... Feel free to reopen if it happens again or file a new bug. Thanks!
The problem seems to still exist with latest fontforge in F10 (fontforge-20080828-1.fc10). I have it and it makes fontforge totally unusable. I build an RPM for myself based on devel, removing the libspiro dependency, and everything worked fine (with a nicer font for the UI). Kevin, would you consider pushing the devel version to F10?
> Kevin, would you consider pushing the devel version to F10? Well, we have talked about doing that in the past, but we need to be very carefull. fontforge is used to build a number of fonts, so we need to make sure the version we push as an update will work to build all the fonts that use it to build in F-10. Otherwise they could be in a bad place if they need to update. Perhaps we could coordinate such a move on the fonts-sig list?
I agree with Kevin: while the problem sounds annoying it is probably safest not to update the fontforge version unless necessary. But by all means discuss on fedora-fonts-list - it would be good to have a firm policy on this. Font developers can hopefully use the build from rawhide in the meantime until F11 is released.
Created attachment 329150 [details] difference between F10 and F11 requirements of fontforge There is something weird going on with F-10's fontforge. Maybe it wasn't built all right or something. Running "rpm -q -R" on it doesn't even list libuninameslist! Attaching a file showing dependency differences between the output of rpm -q -R between what I built on my machine using devel branch of CVS and the latest F-10 rpm.
Yeah, the one in rawhide was built with pango/cairo/spiro support. That support was not available (Or didn't work) when the f10 fontforge was built, so that explains a lot of them. Not sure why libuninameslist isn't in there. :( thats odd. Can you see any ill effect from it? That might be one more reason to try and update f10's fontforge...
I've posted a note to the fonts list to discuss this. Perhaps we should close this bug and continue discussion on that list?
I didn't really get much feedback at all on the list. ;( I am going to close this now... Roozbeh: If you think we should look at pushing a F-10 update, feel free to email me or catch me on irc and we can try and come up with a plan.