| [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #2689
Application: | FLTK Library |
Duplicate Of: | STR #2686 |
Status: | 2 - Closed w/o Resolution |
Priority: | 3 - Moderate, e.g. unable to compile the software |
Scope: | 3 - Applies to all machines and operating systems |
Subsystem: | Core Library |
Summary: | Handling of "@" symbols in fl_draw() and symbol expansion |
Version: | 1.3-current |
Created By: | ianmacarthur |
Assigned To: | ianmacarthur |
Fix Version: | 1.3-current |
Update Notification: | |
Trouble Report Files:
Trouble Report Comments:
|
#1 | ianmacarthur 03:26 Jul 25, 2011 |
| There's somethng a bit weird going on with the expansion of symbols, in particualr the "@" symbol, when using fl_draw.
This was initially flagged in the following thread:
http://www.fltk.org/newsgroups.php?gfltk.general+v:33384
The attached patch I think illustrates the problem.
Or maybe I just don't understand what it's meant to do?
In any case, the behaviour seems wrong.
NOTE: 1.3.x and 1.1.x behave in the same way, as of r8868.
What I see:
A string with a single @ symbol and "draw_symbols" disabled (i.e. not the default draw_symbols state) is *not* correctly drawn if the string has to wrap to fit the box, particularly if the wrap-point occurs within the word that starts with the "@" symbol. If the wrap does not "interact" with the "@" symbol, the string seems to draw more as I'd expect.
In addition, turning off symbol-parsing by starting the string with "@." does not seem to be having quite the effect I'd anticiapted.
I suspect there is something awry with measuring the string and symbol expansion...
The example allows various combinations of escaped (i.e. "@@") and not-escaped strings to be drawn, with and without symbol expansion.
The results are puzzling and not what I had expected.
Is it a bug? I think it may well be. | |
|
#2 | matt 06:05 Aug 03, 2011 |
| Removed Duplicate Of dependency (hopefully) | |
|
#3 | chris 11:05 Oct 02, 2011 |
| The following change seems to fox the case when draw_symbols is off:
Index: src/fl_draw.cxx =================================================================== --- src/fl_draw.cxx (Revision 9116) +++ src/fl_draw.cxx (Arbeitskopie) @@ -304,8 +304,7 @@ if (underline_at && underline_at >= buf && underline_at < (buf + buflen)) callthis("_",1,xpos+int(fl_width(buf,underline_at-buf)),ypos-desc); - - if (!*e || (*e == '@' && e[1] != '@')) break; + if (!*e || (*e == '@' && e[1] != '@' && draw_symbols)) break; p = e; } }
Remark to the test program: What should the output of the test case 3 look like? @. is not valid sequence (this is for the browser escapes) so "@.first" will try to draw the symbol ".first". | |
|
#4 | chris 11:15 Oct 02, 2011 |
| I think the documentation of label symbols can need some more details: First regarding the fact, that there can be only two symbols at most in a string (one at the begin, one at the end) [Not really sure about that - just the source of fl_draw() seems to imply it], then that a found symbol that is not at the begin stops parsing the string. Also how are illegal symbols treated? | |
|
#5 | matt 12:14 Oct 03, 2011 |
| Yes, it's a mix of outdated features and bad documentation. This is a typical case where one idea is abused by "adding just that one little feature". Originally, a label was text *or* a symbol. Then someone said, hey, how about a symbol, followed by text, and it was implemented. Then someone wanted the text first, then the symbol, and it was implemented, etc. etc. . In FLTK 2, symbols can be anywhere, they can even be images, and there are control codes for bold, italics, font size, baseline changes, and more.
I have visited and fixed the label code 20 times or more, and there is always something that doesn't work. And every few months or so, someone files a bug report that EMail addresses can not be a label.
Now this makes me wonder: wouldn't it be easier to just *reduce* the feature set back to either a symbol *or* text, and for everything else, the programmer should use HTML (Fl_Help_View)?
Sorry, just rambling on and on ;-) | |
|
#6 | ianmacarthur 15:59 Mar 11, 2014 |
| It's getting on for 3 years since I posted this one, and to be honest, I doubt we will ever fix it satisfactorily.
Matt maybe had some ideas how, but I certainly do not, and it has not troubled me much (or indeed, at all) in the intervening years...
Might close...? | |
|
#7 | ianmacarthur 16:32 Sep 04, 2014 |
| It's years since I raised this, and I haven't devised a useful fix, nor even been that bothered by it to be honest.
Won't fix... | |
[ Return to Bugs & Features ]
|
| |