[ Return to Bugs & Features | Post Text | Post File | Prev | Next ]

STR #1597

Trouble Report Files:

	Name/Time/Date	Filename/Size
	#1  greg.ercolano 07:42 Feb 12, 2007	foo.html 0k

Trouble Report Comments:

	Name/Time/Date	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 <FONT> 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. <FONT></FONT> (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</font> <ul>   <li><font...>item 1</font></li> </ul> <font...>more text</font> 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><font size=7>item 1</font></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<br>    o Two<br>    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.

[ Return to Bugs & Features | Post Text | Post File ]