| [ Return to Bugs & Features | Post Text | Post File | Prev | Next ]
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: | |
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 <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 ]
|
| |