GNOME Bugzilla – Bug 417704
Font name for missing font should be displayed
Last modified: 2013-05-17 12:01:46 UTC
In the tool options dialog, there's currently no font name displayed when the font is not in Gimp's search path. Steps to reproduce: 1. Put a font file into your ~/.fonts/ (or whereever) 2. Create an XCF image which uses that font in a text layer and save it. 3. Close the Gimp. 4. Delete/ move/ rename that font file. 5. Open the saved image with the gimp. 6. Choose the text tool. 7. Select the text layer. 8. Click on the text layer with the text tool cursor. Result: The font name field in the tool options dialog is empty. Suggested improvements: Either a) display the old font name so that one knows at least the name or b) display something like "<font not installed>" or the like. IMO an empty name field is quite irritating. Other information:
That would be very difficult to implement. It's a corner case and I doubt that it's worth to try to implement this. I will leave this report open for now but we might decide to close it as WONTFIX.
I am not sure about what is the best solution, but I would like to keep this bug open because I have experienced the same problem a couple of times. This happened to me when working with GIMP on different machines (at home, at work, etc.) having slightly different sets of fonts available. When I opened an XCF file that I created on another machine, it was hard for me to know what font I had to install in order to get the expected results with the text. Ideally, the font name field or some other widget (maybe the status bar) should display both a description of the problem and the name of the font that could not be found. Something like "Missing font <font name>" or more if there is room for it.
Just adding a 'me too' with a few comments. I do disagree with sven in Comment #1 that it's an edge case, I've got well over 10,000 gimp files saved spanning 5+ years. And I certainly do not have all those fonts installed it's a great pain to open the xcf and search around to find what the old font names are. To that end, if it's difficult to impliment the old fontname in the font name box (greyed out), is it possible to atleast have an option in the file menu perhaps? Like 'locate fonts' and have a dialogue box come up with a list of the fonts used in the XCF and wether they're installed or not?
Changing version to "Current SVN" as this request is not specific to any particular version.
Hi, continuing discussion that we got on bug 689523. To sum-up: 1/ there has been propositions about displaying a pop-up (by me, and a patch for this) telling what's wrong. Some people were worried a pop-up was too intrusive. I can understand this, though I think it is important that the user sees that something is wrong and this is *NOT* because of GIMP. The user is the only one who can fix it. But for this one needs to know the name of the original font and to be explained clearly the problem (otherwise it only looks like a bug, even though it is not). 2/ there have been propositions to lock the text layer until you install the right font. I strongly go against this proposition. There are cases where you can't find, or with difficulty, some fonts anymore, even when knowing the name; and where just changing to another font available on your system suits you perfectly. 3/ My last proposition is this: when the font name displayed is different from the font actually used, the font name could be displayed in red in the text editor (and when you mouse over the red font name, the help bubble says something like "font unavailable on this system")? What do you think of this? That's non-intrusive, but still provides a good visual hint (red) to spot the existence of a problem.
I'm all for 3.
Maybe combined with also changing the color of the text layer, possibly with an appropriate mouse-over hint? Still not very intrusive, but visible at a glance without having to select the text layer. Otherwise the unavailability of a font would easily go unnoticed.
Daniel: the problem with your proposition is that you are also implying that we already know all the text layers whose font is absent from the start. Hence it would mean checking existence of all fonts at image-load time. Actually in the current implementation, that's not what happens. We only check a font existence when you start to edit a text (you click a text layer with the text tool). If you have a file using thousands of fonts (ok that's mostly surrealist, but I was given this example in the other bug report), then you would check thousands of fonts at load-time. In other words, it does not scale well. Of course, that's an edge case. We could still do it, but I think that's not necessary anyway. Indeed I would say that it does not matter at all that the unavailability of a font goes unnoticed. It only matters when you want to edit the text: changing the text contents, its size or its style (bold, italic, etc.). But as long as you don't do any text edition, the text will still be viewable in the original font, and you can even perform graphical modifications on it (moving it, rotation, filters, etc.). Basically nobody cares to see the unavailability of a font before text edition, because that's only blocking text edition, as far as I could see.
OK, if the rendered text is available already from the xcf, you are right of course. It's sufficient to show that there's something wrong as soon as there are unwanted effects.
Created attachment 233848 [details] [review] Patch displaying the font name in red + adapted help message when absent font Attached the patch.
That patch does what I meant, great. But... it would be infinitely cooler if it worked directly in GimpContainerEntry, somehow, so would cover the font entry in tool options too, and all other data types.
Hi, ok I'll see at this. May not be for the next few days though. But I will. :-)
Hi Mitch, I finally had a look at this. The font entry in the tool options is not a GimpContainerEntry as well. It is a GimpSizeEntry. And with different parents (respectively GtkEntry and GtkTable) so their closest common ancester is GtkWidget. So if I were to make some function specific to GimpContainerEntry, it would not be useful for the similar font entry in the tool options. But probably I could make a generic function in libgimpwidgets which would work for any widget, to set it in some generic "warning/error" mode. Should I go this way?
The font entry in tool options is not a GimpSizeEntry, it is constructed with gimp_prop_font_box_new().
Hmmm... ok well it would still look to me as these are different classes. If I follow the code, gimp_prop_font_box_new returns ultimately a GimpContainer, not a GimpContainerEntry. Anyway I'll make some actual tests in the code rather than actually reading it and bothering you. I'll see what can be done to make my code more generic.
Created attachment 242634 [details] [review] GimpContainerEntry's text is red when not a valid item. So I broke in 2 patches, though I am not fully happy about it. I imagine it can be done better. The first patch is done on GimpContainerEntry as requested. So it will work with any other similar GimpContainerEntry (font, brush, dynamics, etc.). Basically if the selected item (directly for instance when saved in the file, which can be the case of a font) is not valid, the text in the entry is red. I also set it red when the entry is being edited and the current value is not valid (so for instance in case of user input by keyboard, etc.). Unfortunately in the case of a wrongly selected item like our absent font case, this patch would not display the expected font name in red, but the actual set font in red. This is the part I am not happy with because I could not find how to have the expected behavior fully on the GimpContainerEntry generic level, which would be ideal to support all kind of entries from this common piece of code. My problem was that in gimp_container_entry_select_item() in particular, I could not find the expected selected item information. If it is an invalid item, `insert_data` would be NULL and `gimp_object_get_name (viewable)` or `gtk_entry_get_text (entry)` would return the actual item's name, not the expected one. So this is why there is a second patch just for the font case where I would set the expected font name in the help message. Mitch, or anyone else, if you know how I can get this information in the GimpContainerEntry level, please tell me; and I'll update this patch to be full generic. Otherwise that's the current proposition half generic, half font-specific.
Created attachment 242635 [details] [review] font name for missing font is known in the font entry's help message.
Review of attachment 242635 [details] [review]: I don't thing we need that boolean in the context. It's enough to check if the font's name is the same as font_name. Also, there is g_strdup_printf().
Comment on attachment 242634 [details] [review] GimpContainerEntry's text is red when not a valid item. I think this is fine, please push.
As for attachment 242635 [details] [review]: for the font name, I guess you are right. And I indeed saw this g_strdup_printf() after I uploaded the patch. Nevertheless I did not update because I was in particular interested by whether or not we have access to the expected resource name at the GimpContainerEntry level. Depending on the answer to this, as I could not find by myself, this second attachment may be useless because it will be much nicer to implement this at such a lower level so that we could generate the missing resource help text for anything which uses GimpContainerEntry.
In the meantime, I pushed the first part of the fix on master and gimp-2-8: commit 64fe3af1a913bb61953b6faf727f3cf9700167b7 Author: Jehan <jehan@girinstud.io> Date: Sat Apr 27 11:26:04 2013 +0900 app: GimpContainerEntry's text is red when not a valid item. If the selected item in a GimpContainerEntry is invalid, or else when the entry is being updated, the text shows in red.
Created attachment 242761 [details] [review] Missing font name in the help message And here is the second patch updated (using g_strdup_printf() and removing the boolean). That's nicer indeed but if the whole logics could go into GimpContainerEntry, that would be better. Yet I still don't know how to get the expected resource set in the entry from GimpContainerEntry code. :-/
Review of attachment 242634 [details] [review]: I'm afraid this patch completel breaks the completion popup in the most absurd way. E.g. for "Arial", it works for "ar", then when typing "ari", the popup shrinks to a some-pixel wide window. It generally behaves very fishy. We can't have that in 2-8, please revert, but leave it in master for the time being, maybe we can fix it.
Review of attachment 242761 [details] [review]: Thanks that looks much better, but we have a general policy to stay within 80 columns of source, if possible.
Hi, for attachment 242634 [details] [review], I did not see the popup shrinking at all. I don't really understand. Anyway I reverted in 2-8. That's minor. For 242761, I'll update.
Created attachment 243615 [details] [review] Missing font name in the help message Updated the line widths for the second patch (in one case, it is still 81 columns though, I hope that's ok).
Created attachment 243616 [details] [review] Missing font name in the help message
Comment on attachment 243616 [details] [review] Missing font name in the help message Looks good to me, please push to master.
commit 53d2059bd8b1271d02129c4a9ed35a0497c34ab1 Author: Jehan <jehan@girinstud.io> Date: Sat Apr 27 11:29:19 2013 +0900 Bug 417704: font name for missing font is given in the font entry's help message. When a font is missing, the name of the expected font will be displayed in the help message through the text style editor with an explanatory message.