GNOME Bugzilla – Bug 167260
NEON fu-script broken
Last modified: 2008-01-15 12:47:48 UTC
Try to render the any string not starting with "N".
Doesn't seem to depend only on the rendered string. If you select a font that is actually available (in contrast to the default font which is probably not installed on most systems), then any string seems to be rendered fine.
Not for me. I changed to font that is definitly available and it stills fails. Actually it works with the default font though that is not installed. Does it backup to some standard font?
Pango, which is the library we use for font rendering, provides a font fallback mechanism.
For me, the version of Neon in the Toolbox Xtns menu works fine in every respect. It is the version in the Image->Script-fu->Alpha to Logo menu that sometimes has trouble. It looks to me like the script fails when the effect size exceeds the vertical span of the font -- so, for example, changing the string from "Neon" to "eon" can cause it to fail for a certain range of effect sizes.
Fixing this probably requires being able to know the size of the font for a text layer. This information is not currently available in the pdb. Thus, this bug probably depends on bug #164539.
So which version do You use to render the string "Alles" successfully?
It works fine for me using the Toolbox version, or using the Image version if the font is large enough. If you have problems in these cases, I wonder if they might be caused by the locale-related problems Script-fu suffers from.
This is certainly not a locale-specific problem. Script-Fu works fine as long as the script doesn't try to access individual characters from a string. Only text-circle is doing that. The problem reported here seems to go away (for a sans font at 150 pixels) with the following change: - (shrink (/ size 14)) + (shrink (/ size 20)) I haven't yet understood why the text "eon" triggers the problem, the text "Neon" however, in the same font and same font-size, works fine.
Essentially to repeat comment #5, I believe that to make this work, the script needs to know the size of the text it is working on, and that information won't be available until something is done about bug #164539. Even if that happens, the changes won't be backported, so I am going to bump the target here.
Unless someone can post a set of steps to follow which will make this script fail repeatedly this problem won't be resolved. I have tried on several occasions to make it fail in both 2.2.x and CVS GIMP. I have never encountered the problem reported.
The following information is from a message in comp.graphics.apps.gimp by Paul dated Sat, 12 Feb 2005 16:10:59 +0100. Adding it since it has a better summary of the original problem being reported and will be a reminder of a test case or two for me to try in the hopes of reproducing the problem. > I need some help with the NEON fu-script. It works with the standard > string "NEON" but when changing it to "neon" or for example "Alles" it > fails. The occurs no error as it doesn't crash but one only gets an image > of the foreground color.
Recipe to repeat: first, create a text layer, using font "Sans" at size 100, with the text "Neon". Next, from the image menu (*not* the Toolbox), activate Filers->Alpha to Logo->Neon (this is for cvs gimp). Use the default settings, which set the effect size to 100, among other things. Note that it works. Undo the result, and edit the text layer to erase the initial "N", leaving the text as "eon". Run the script again, with the same settings. Note that you just get a solid layer as the result. As I wrote in comment #4, my experiments indicate that the relationship of the vertical span of the text to the effect size in the script is what determines whether it will work.
Bumping to Future because a proper fix depends on improvements in the pdb text api, which will not happen for 2.4.
I sat down and used Tiny-Fu console to do some debugging of the Neon script to see if I could reproduce the problem determine what was going wrong. It turns out that Sven was on the right track that problem is related to the value for 'shrink'. The problem occurs at the point the script calls gimp-selection-shrink. If you use a large value for the font size and you use a font with thin letters the value of shrink can be almost equal to or more than half the width of the font strokes. As a result, the call to gimp-selection-shrink makes the selection shrink to where GIMP just deletes the selection. After that the script will fail to work as desired since the selection is still required after this point. The problem can be fixed without a new API. The value calculated for shrink needs to be constrained to a maximum value that is less than half the width of a font stroke.
Yes, but there is no way to figure out the width of a font stroke. There is no API to take a text layer and extract information from it about the text. As far as the PDB is concerned, a text layer is indistinguishable from any other kind of layer: there is not even a gimp-layer-is-text function right now.
I have an idea for a possible solution that does not require any new API. It is an idea borne of something I saw in the text circle script. The idea is to create a text layer with a period character on it, autocrop the layer, then get the layer width. This value should then give a rough idea of character stroke width and can be used in determining a reasonable value for shrink variable based on the chosen font.
Note comment #4. Text Circle can do these things because it knows what text it is trying to render. The version of Neon in the Toobox menu also runs without any problem, at least in my hands, because it has access to the text. It is only the version in the image menu that is problematic. That version does not have any access whatsoever to the text in the layer. In fact, nothing prevents it from being run on non-text layers.
I forgot about the entry in the image menu. I know that comment #4 says the Toolbox Xtns menu worked fine for you but it using that menu which allowed me to reproduce the problem and determine what was causing the bad behaviour. A way to fix this would be to mark the existing neon script interface calls as deprecated and create new menu entries which allow a user to have more control over the effect. Currently the "Effect size" entered (or the font size in the case of the Logo menu entry) is used to calculate all values which determine the look of the effect. Depending on the image (or font), these calculated values will sometimes cause problems.
The problem I have seen stems from values of shrink larger than the width and/or height of a selection. After the shrink operation on the selection the selection no longer exists. I think a more generic solution in the short term is to check after shrink operations whether a selection still exists. If the selection no longer exists provide a message to the user that the neon affect can not be applied using the current image or font.
There is no need to limit ourselves to text layers. This script works perfectly well with other layers too. The only thing the behaviour depends on is drawable width & height. IMO, there is no need to show error message, but instead we could determine if chosen values would trigger the bug. If so, variables could be clamped to valid range. Some experimentation shows that size parameter should be ~ (drawable_width / 2.6) (I tested with drawable_width > drawable_height). Real solution should probably take drawable_height into account too, I guess.
Comment #20 sounds like a reasonable solution to me. A patch would be very much appreciated.
Created attachment 86421 [details] [review] Don't allow neon to shrink selection too much This is not as elegant as I first expected. Nonetheless, it does what it should. If shrink is in valid range, the script works as before. Otherwise, shrink values are clamped to upper bound. BTW, it gives some interesting effects if used with large effect size values.
Looks good except for the two lines that are popping and pushing the context. What's that good for?
It seems they are useless because the script doesn't care that new code screws up selection.
2007-04-17 Sven Neumann <sven@gimp.org> * plug-ins/script-fu/scripts/neon-logo.scm: applied slightly modified patch from Aurimas Juška which fixes bug #167260 by not allowing the selection to shrink too much.