FLTK logo

STR #2689

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

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:

Receive EMails Don't Receive EMails

Trouble Report Files:


Name/Time/Date Filename/Size  
 
#1 ianmacarthur
03:26 Jul 25, 2011
draw_test.cxx
5k
 
     

Trouble Report Comments:


Name/Time/Date Text  
 
#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 ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.