STR #1597: Fl_Help_View: HTML problems with font size + <UL>

STR #1597

Application:	FLTK Library
Status:	5 - New
Priority:	2 - Low, e.g. a documentation error or undocumented side-effect
Scope:	3 - Applies to all machines and operating systems
Subsystem:	Core Library
Summary:	Fl_Help_View: HTML problems with font size + <UL>
Version:	1.4-feature
Created By:	greg.ercolano
Assigned To:	Unassigned
Fix Version:	Unassigned
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

Post File

#1	greg.ercolano 07:42 Feb 12, 2007

foo.html
0k

Trouble Report Comments:

Post Text

#1	greg.ercolano 07:43 Feb 12, 2007

Loading the attached foo.html into the FLTK test/help program, note the font size is lost at the start of the <UL> list. By the end of the <UL> list, the color remains the same, but the font size is still lost.

#2	greg.ercolano 07:45 Feb 12, 2007

Also of note: if 'FACE=COURIER' is added to the line, the font face is lost as well when the <UL> list is encountered. Seems the only thing that survives past the <UL> is the font color.

#3	matt 07:23 Feb 13, 2007

Um, no. (HTML 3.2) may only contain inline elements which do not do any block formatting. <UL> however does do block formatting. The correct HTML code would be: <font...>my text above the list <ul> <li><font...>item 1</li> </ul> <font...>more text Silly, I know. Or you would use the tag <BASEFONT...> (HTML 4.0), but Fl_Help_View does not support that. Yes, I know, most browsers do not care, and the font is not reset to the page font. So I will leave it to Mike to decide if he wants to "fix" the correct behavior of Fl_Help_View.

#4	greg.ercolano 09:08 Feb 13, 2007

Hmm, that can't be right, though.. if I do: <li>item 1</li> ..it doesn't look right in any browser; you end up with a 'base font size' bullet next to the different sized font. So if the font is large, instead of getting a font sized bullet (here comes some ascii art..): ___ /\ | _ ___ \/ | /_\ \/ | | \_ /\ |_ ..you get instead: ___ | _ ___ | /_\ \/ | o | \_ /\ |_ It seems all the browsers are consistent in how that's displayed, including Fl_Help_View. Since there doesn't seem a way to change the base font, maybe what I can do for my docs is just make my index bullets by hand: <UL> o One o Two o Three </UL> That seems to at least "look OK" for government work.. few will be able to tell the difference ;) I've always hated the HTML spec.. it ignores so many practical needs, it just isn't funny.

#5	matt 04:09 Feb 25, 2007

Well, in a perfect world the indent and the size of the dot would correspond to the size of the first character printed.

#6	matt 05:04 Feb 25, 2007

Mike, I have been trying to understand the relevant code, but can't figure it out all the way. Would you please take care of this one? Thanks.

#7	matt 07:36 May 02, 2007

OK, I finally figured out what needs to be done. However, this is pretty involved and requires some code reorg and changes in a public class. I hance pushed this up to 1.2. As a reminder, this needs to be done: Fl_Help_View assumes that the font and size are reset to the document default at the beginning of a new block (P, UL, LI, H1, etc. tags). Even though this is correct HTML, all current browsers keep fonts, font sizes, and even the font color across most of these tags (it would be important to figure out for which ones exactly). Anyway, since our optimized code renders only visible blocks, we must keep track of these attributes inside Fl_Help_Block. We must also verify for every command that the correct font height is used for indents and vertical line feeds (currently, we use the height of the last explicitly set font to advance before a UL, even if the font size was reset to the default a while ago). There are also numerous limitations based on hardcoded array sizes.