GNOME Bugzilla – Bug 313742
GtkTextView text issues with incorrect font setting
Last modified: 2018-05-22 12:11:46 UTC
Please describe the problem: With a GTK Source View widget, if one sets the font to one that doesn't exist; pressing the Enter does not advance existing text down a line. The issue appears to be due to crlf not being correctly managed. If you enable line numbers on the LHS of the GTKSourceview, these play up too. * The fix to the problem was to put in a font that existed. * None of these problems were observed under Linux. Steps to reproduce: 1.Modify code... pfd = pango_font_description_from_string("Some random font name"); gtk_widget_modify_font(GTK_WIDGET(sourceview), pfd); 2. recompile 3. Run and press enter in the gtksourceview. Actual results: no new lines generated in gtksourceview when pressing enter Expected results: new lines be generated in gtksourceview Does this happen every time? yes Other information:
If you can reproduce with a plain GtkTextView, reassign to GTK+. If someone tracks it down in GTK+ and it's a Pango problem, then reassign to Pango.
Possible bugs in GtkSourceView/GtkTextView aside, shouldn't pango complain when you try to create a new PangoFontDescription with a font string that doesn't exist?
Because of the nature of fontconfig, Pango has no idea whether a font exists or not ... you give fontconfig a font name, it will give you a font back. the font name might be an alias, it might be a real font on the system, it might have ignored the name because it wasn't found and given you some random font matching the other fields.
Joseph: you said "None of these problems were observed under Linux.". On which OS you observed them? Could you please try to reproduce this problem modifying the testtext program you find in gtk+/tests?
ok. Platform: WINDOWS - observed under windows 2000 and XP, no idea about other Windows platforms. I've always had problems compiling the test cases under windows. so instead I've created a program to replicate this issue (source and binary). Please find it as an attachment. Will also need to download gtk for windows. http://leederville.net/~joeman/gtk+-2.6.9-setup.exe.
Created attachment 56661 [details] source, executable of issue Run the application test.exe - DO the following to replicate the issues First line type 'happy' (hit enter) Second line type 'days' (press the up key to go to previous line and go to end of first line) Enter some more text on first line (hit enter) You should see the numbers mucked up on the LHS.
Created attachment 56668 [details] Source/executables to replicate issue. Able to replicate issue using textview widget instead of sourceview widget. Will reassign and change component. Please see attachment - test1.* the textview versions.
Since Joseph has beed able to reproduce this bug without GtkSoureView, I'm going to change the produce to gtk+/GtkTextView
paolo joe: which version of gtk+/pango are you using? joe pango 1.8.2 joe gtk+ 2.6.9
the issue is specific to win32
Hmm, isn't this a case of garbage in, garbage out...? Most probably the problem is in Pango, not GTK+
AFAIU with PangoX and PangoWin32 backends, if no font exists, a font metrics of all zero is returned. Since fallback seems to be broken on Win32, this is probably what's happening.
Do you mean some backend-specific fallback mechanism? I don't think there has ever been such in pangowin32. Or do you mean that the generic fallback mechanism doesn't work with the pangowin32 backend? That is not entirely true, inputting printable letters or lines with just whitespace (at least one space) in the test program does work. (And produces the warning 'couldn't load font "Foobar 8", falling back to "Sans 8", expect ugly output.' It's completely empty lines in the textview that don't make use of the Sans 8 fallback for some reason and are then apparently measured as zero.
Sounds like pango_layout_line_get_empty_extents() might have a win32-specific issues?
Probably. Isn't it backend-independend code that falls back to "Sans 8" instead of "Foobar 8" for non-empty lines, though? Why doesn't this happen for empty lines?
Here is the reason: The "Sans" fallback happens in pango_font_map_load_fontset, while pango_layout_line_get_empty_extents calls pango_context_load_font which in turn calls pango_font_map_load_font (not fontset), which is backend-specific and does not fallback to Sans or anything. And apparently we have if (font) ... else logical_rect->height = 0 in empty_extents. The way the FcFontMap works it that it implements load_font as get_first_font (load_fontset). That's why you get all those fallbacks and all. Any chance Win32 can be changed to do the same?
See also discussion in bug #310700
I just wanted to report the practically the same bug, but I've managed to find this report. See attachment for the sample code. In my test code, this bug appears only on Windows (GTK 2.22.0). Tested on Linux too using Fedora 12 (GTK 2.18.6) and Ubuntu 11.04 (GTK 2.24.x) but the bug does not seem to be present there. To reproduce the bug: go to the end of any text line and press Enter, nothing happens, new line does not seem to be added. I'd personally vote to give this bug the highest priority because it destroys the usage of the text editing when two users exchange formatted documents, and one user not having all the the fonts used in the document.
Created attachment 198911 [details] Sample code to show the bug
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/pango/issues/29.