STR #1597

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 | 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>
Created By:greg.ercolano
Assigned To:Unassigned
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size top right image
#1 greg.ercolano
07:42 Feb 12, 2007
bottom left image   bottom right image

Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
#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>
  <li><font...>item 1</font></li>
<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> 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..):
    /\   |   _     ___
    \/   |  /_\ \/  |
         |  \_  /\  |_ 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:

   o One<br>
   o Two<br>
   o Three

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.
bottom left image   bottom right image

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


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