more html to doxygen conversion for {osissues,migration*,development}.dox

git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@6410 ea41ed52-d2ee-0310-a9c1-e6b18d33e121

4 files changed, 430 insertions, 347 deletions

diff --git a/documentation/development.dox b/documentation/development.dox
index af5058215..f733438ae 100644
--- a/documentation/development.dox
+++ b/documentation/development.dox
@@ -2,8 +2,7 @@
 
  \page development I - Developer Information
 
-<P>This chapter describes FLTK development and documentation.
-</P>
+This chapter describes FLTK development and documentation.
 
 \note	documentation with doxygen will be described here.
 
@@ -247,6 +246,7 @@ The following section is
 	\section development_links Creating Links
   \endcode
 
+
 \section development_links Creating Links
 
 Links to other documents and external links can be embedded with
@@ -341,6 +341,68 @@ becomes:
 
 \endcode
 
+
+\section development_paragraphs Paragraph Layout
+
+There is no real need to use HTML \<P\> and \</P\> tags within the text
+to tell doxygen to start or stop a paragraph. In most cases, when doxygen
+encounters a blank line or some, but not all, \b \\commands in the text it
+knows that it as reached the start or end of a paragraph. Doxygen also
+offers the \b \\par command for special paragraph handling. It can be used
+to provide a paragraph title and also to indent a paragraph. Unfortunately
+\b \\par won't do what you expect if you want to have doxygen links and
+sometimes html tags don't work either.
+
+  <!-- use verbatim rather than code to avoid links to code reference -->
+  \verbatim
+    \par Normal Paragraph with title
+
+    This paragraph will have a title, but because there is a blank line
+    between the \par and the text, it will have the normal layout.
+
+    \par Indented Paragraph with title
+    This paragraph will also have a title, but because there is no blank
+    line between the \par and the text, it will be indented.
+
+    \par
+    It is also possible to have an indented paragraph without title.
+    This is how you indent subsequent paragraphs.
+
+    \par No link to Fl_Widget::draw()
+    Note that the paragraph title is treated as plain text.
+    Doxygen type links will not work.
+    HTML characters and tags may or may not work.
+
+    Fl_Widget::draw() links and &quot;html&quot; tags work<br>
+    \par
+    Use a single line ending with <br> for complicated paragraph titles.
+  \endverbatim
+
+The above code produces the following paragraphs:
+
+    \par Normal Paragraph with title
+
+    This paragraph will have a title, but because there is a blank line
+    between the \\par and the text, it will have the normal layout.
+
+    \par Indented Paragraph with title
+    This paragraph will also have a title, but because there is no blank
+    line between the \\par and the text, it will be indented.
+
+    \par
+    It is also possible to have an indented paragraph without title.
+    This is how you indent subsequent paragraphs.
+
+    \par No link to Fl_Widget::draw()
+    Note that the paragraph title is treated as plain text.
+    Doxygen type links will not work.
+    HTML characters and tags may or may not work.
+
+    Fl_Widget::draw() links and &quot;html&quot; tags work<br>
+    \par
+    Use a single line ending with \<br\> for complicated paragraph titles.
+
+
 \section development_html_footer Hack for missing "tiny.gif" file
 
   \todo
diff --git a/documentation/migration_1_1.dox b/documentation/migration_1_1.dox
index 2f1533675..544532108 100644
--- a/documentation/migration_1_1.dox
+++ b/documentation/migration_1_1.dox
@@ -2,51 +2,52 @@
 
  \page	migration_1_1	G - Migrating Code from FLTK 1.0 to 1.1
 
-<P>This appendix describes the differences between the FLTK
-1.0.x and FLTK 1.1.x functions and classes.</P>
 
-<H2>Color Values</H2>
+This appendix describes the differences between the FLTK
+1.0.x and FLTK 1.1.x functions and classes.
 
-<P>Color values are now stored in a 32-bit unsigned integer
+\section migration_1_1_color Color Values
+
+Color values are now stored in a 32-bit unsigned integer
 instead of the unsigned character in 1.0.x. This allows for the
 specification of 24-bit RGB values or 8-bit FLTK color indices.
 
-<P><TT>FL_BLACK</TT> and <TT>FL_WHITE</TT> now remain black and 
+<tt>FL_BLACK</tt> and <tt>FL_WHITE</tt> now remain black and 
 white, even if the base color of the gray ramp is changed using 
-<A HREF="Fl.html#Fl.background"><TT>Fl::background()</TT></A>.
-<TT>FL_DARK3</TT> and <TT>FL_LIGHT3</TT> can be used instead to 
-draw a very dark or a very bright background hue.</P>
+<A HREF="Fl.html#Fl.background"><tt>Fl::background()</tt></A>.
+<tt>FL_DARK3</tt> and <tt>FL_LIGHT3</tt> can be used instead to 
+draw a very dark or a very bright background hue.
 
-<P>Widgets use the new color symbols <TT>FL_FORGROUND_COLOR</TT>,
-<TT>FL_BACKGROUND_COLOR</TT>, <TT>FL_BACKGROUND2_COLOR</TT>, 
-<TT>FL_INACTIVE_COLOR</TT>, and <TT>FL_SELECTION_COLOR</TT>.
+Widgets use the new color symbols <tt>FL_FORGROUND_COLOR</tt>,
+<tt>FL_BACKGROUND_COLOR</tt>, <tt>FL_BACKGROUND2_COLOR</tt>, 
+<tt>FL_INACTIVE_COLOR</tt>, and <tt>FL_SELECTION_COLOR</tt>.
 More details can be found in the chapter
-<A HREF="enumerations.html#colors">Enumerations</A>.</P>
+<A HREF="enumerations.html#colors">Enumerations</A>.
 
-<H2>Cut and Paste Support</H2>
+\section migration_1_1_cutnpaste Cut and Paste Support
 
-<P>The FLTK clipboard is now broken into two parts - a local
+The FLTK clipboard is now broken into two parts - a local
 selection value and a cut-and-paste value. This allows FLTK to
 support things like highlighting and replacing text that was
 previously cut or copied, which makes FLTK applications behave
 like traditional GUI applications.
 
-<H2>File Chooser</H2>
+\section migration_1_1_file_chooser File Chooser
 
-<P>The file chooser in FLTK 1.1.x is significantly different
+The file chooser in FLTK 1.1.x is significantly different
 than the one supplied with FLTK 1.0.x. Any code that directly
-references the old <TT>FCB</TT> class or members will need
-to be ported to the new <A
-HREF="Fl_File_Chooser.html"><TT>Fl_File_Chooser</TT></A>
-class.</P>
+references the old <tt>FCB</tt> class or members will need
+to be ported to the new
+<A HREF="Fl_File_Chooser.html"><tt>Fl_File_Chooser</tt></A>
+class.
 
-<H2>Function Names</H2>
+\section migration_1_1_functions Function Names
 
-<P>Some function names have changed from FLTK 1.0.x to 1.1.x in
+Some function names have changed from FLTK 1.0.x to 1.1.x in
 order to avoid name space collisions. You can still use the old
-function names by defining the <TT>FLTK_1_0_COMPAT</TT>
+function names by defining the <tt>FLTK_1_0_COMPAT</tt>
 symbol on the command-line when you compile
-(<TT>-DFLTK_1_0_COMPAT</TT>) or in your source, e.g.:
+(<tt>-DFLTK_1_0_COMPAT</tt>) or in your source, e.g.:
 
 \code
 #define FLTK_1_0_COMPAT
@@ -55,9 +56,10 @@ symbol on the command-line when you compile
 #include <FL/filename.H>
 \endcode
 
-<P>The following table shows the old and new function names:</P>
+The following table shows the old and new function names:
 
-<CENTER><TABLE WIDTH="80%" BORDER="1">
+<CENTER>
+<TABLE WIDTH="80%" BORDER="1">
 <TR>
 	<TH>Old 1.0.x Name</TH>
 	<TH>New 1.1.x Name</TH>
@@ -118,37 +120,40 @@ symbol on the command-line when you compile
 	<TD>numericsort()</TD>
 	<TD>fl_numericsort()</TD>
 </TR>
-</TABLE></CENTER>
+</TABLE>
+</CENTER>
 
-<H2>Image Support</H2>
+\section migration_1_1_images Image Support
 
-<P>Image support in FLTK has been significantly revamped in
-1.1.x. The <A HREF="Fl_Image.html"><TT>Fl_Image</TT></A> class
+Image support in FLTK has been significantly revamped in
+1.1.x. The <A HREF="Fl_Image.html"><tt>Fl_Image</tt></A> class
 is now a proper base class, with the core image drawing
-functionality in the <A
-HREF="Fl_Bitmap.html"><TT>Fl_Bitmap</TT></A>, <A
-HREF="Fl_Pixmap.html"><TT>Fl_Pixmap</TT></A>, and <A
-HREF="Fl_RGB_Image.html"><TT>Fl_RGB_Image</TT></A> classes.
-
-<P>BMP, GIF, JPEG, PNG, XBM, and XPM image files can now be
-loaded using the appropriate image classes, and the <A
-HREF="Fl_Shared_Image.html"><TT>Fl_Shared_Image</TT></A> class
-can be used to cache images in memory.
-
-<P>Image labels are no longer provided as an add-on label type.
-If you use the old <TT>label()</TT> methods on an image, the
-widget's <TT>image()</TT> method is called to set the image
+functionality in the
+<A HREF="Fl_Bitmap.html"><tt>Fl_Bitmap</tt></A>,
+<A HREF="Fl_Pixmap.html"><tt>Fl_Pixmap</tt></A>,
+and
+<A HREF="Fl_RGB_Image.html"><tt>Fl_RGB_Image</tt></A>
+classes.
+
+BMP, GIF, JPEG, PNG, XBM, and XPM image files can now be
+loaded using the appropriate image classes, and the
+<A HREF="Fl_Shared_Image.html"><tt>Fl_Shared_Image</tt></A>
+class can be used to cache images in memory.
+
+Image labels are no longer provided as an add-on label type.
+If you use the old <tt>label()</tt> methods on an image, the
+widget's <tt>image()</tt> method is called to set the image
 as the label.
 
-<P>Image labels in menu items must still use the old labeltype
+Image labels in menu items must still use the old labeltype
 mechanism to preserve source compatibility.
 
-<H2>Keyboard Navigation</H2>
+\section migration_1_1_keyboard Keyboard Navigation
 
-<P>FLTK 1.1.x now supports keyboard navigation and control with
+FLTK 1.1.x now supports keyboard navigation and control with
 all widgets. To restore the old FLTK 1.0.x behavior so that only
-text widgets get keyboard focus, call the <A
-HREF="Fl.html#Fl.visible_focus"><CODE>Fl::visible_focus()</CODE></A>
+text widgets get keyboard focus, call the
+<A HREF="Fl.html#Fl.visible_focus"><CODE>Fl::visible_focus()</CODE></A>
 method to disable it:
 
 \code
diff --git a/documentation/migration_1_3.dox b/documentation/migration_1_3.dox
index d22f1c439..b86c335c6 100644
--- a/documentation/migration_1_3.dox
+++ b/documentation/migration_1_3.dox
@@ -2,8 +2,8 @@
 
  \page	migration_1_3	H - Migrating Code from FLTK 1.1 to 1.3
 
-<P>This appendix describes the differences between the FLTK
-1.1.x and FLTK 1.3.x functions and classes.</P>
+This appendix describes the differences between the FLTK
+1.1.x and FLTK 1.3.x functions and classes.
 
 If you want to migrate your code from FLTK 1.0 to FLTK 1.3,
 then you should also consult Appendix \ref migration_1_1.
diff --git a/documentation/osissues.dox b/documentation/osissues.dox
index 1b9d082f9..baf0e437a 100644
--- a/documentation/osissues.dox
+++ b/documentation/osissues.dox
@@ -2,107 +2,115 @@
 
  \page	osissues	F - Operating System Issues
 
-<P>This appendix describes the operating system specific interfaces in FLTK.
+This appendix describes the operating system specific interfaces in FLTK.
 
-<H2>Accessing the OS Interfaces</H2>
+\section osissues_accessing Accessing the OS Interfaces
 
-<P>All programs that need to access the operating system
+All programs that need to access the operating system
 specific interfaces must include the following header file:
 
 \code
 #include <FL/x.H>
 \endcode
 
-<P>Despite the name, this header file will define the
+Despite the name, this header file will define the
 appropriate interface for your environment. The pages that
 follow describe the functionality that is provided for each
 operating system.
 
-<CENTER><TABLE WIDTH="90%" BORDER="1" CELLPADDING="5" CELLSPACING="0" BGCOLOR="#cccccc">
+<CENTER>
+<TABLE WIDTH="90%" BORDER="1" CELLPADDING="5" CELLSPACING="0" BGCOLOR="#cccccc">
 <TR>
 	<TD><B>WARNING:</B>
 
-	<P>The interfaces provided by this header file may
+	The interfaces provided by this header file may
 	change radically in new FLTK releases. Use them only
 	when an existing generic FLTK interface is not
-	sufficient.</P>
+	sufficient.
 
 	</TD>
 </TR>
-</TABLE></CENTER>
+</TABLE>
+</CENTER>
 
-<H2>The UNIX (X11) Interface</H2>
+\section osissues_unit The UNIX (X11) Interface
 
-<P>The UNIX interface provides access to the X Window System
+The UNIX interface provides access to the X Window System
 state information and data structures.
 
-<H3>Handling Other X Events</H3>
+\subsection osissues_x_events Handling Other X Events
 
-<H4><A name="add_handler">void Fl::add_handler(int (*f)(int))</A></H4>
+<A name="add_handler"></A> <!-- For old HTML links only ! -->
+void Fl::add_handler(int (*f)(int))
 
-<P>Installs a function to parse unrecognized events. If FLTK
+Installs a function to parse unrecognized events. If FLTK
 cannot figure out what to do with an event, it calls each of
 these functions (most recent first) until one of them returns
 non-zero. If none of them returns non-zero then the event is
 ignored.
 
-<P>FLTK calls this for any X events it does not recognize, or X
+FLTK calls this for any X events it does not recognize, or X
 events with a window ID that FLTK does not recognize. You can
-look at the X event in the <A
-href="#fl_xevent"><TT>fl_xevent</TT></A> variable.</P>
+look at the X event in the
+<A href="#fl_xevent"><tt>fl_xevent</tt></A> variable.
 
-<P>The argument is the FLTK event type that was not handled, or
+The argument is the FLTK event type that was not handled, or
 zero for unrecognized X events. These handlers are also called
 for global shortcuts and some other events that the widget they
 were passed to did not handle, for example
-<TT>FL_SHORTCUT</TT>.</P>
+<tt>FL_SHORTCUT</tt>.
 
-<H4><A name="fl_xevent">extern XEvent *fl_xvent</A></H4>
+<A name="fl_xevent"></A> <!-- For old HTML links only ! -->
+extern XEvent *fl_xvent
 
-<P>This variable contains the most recent X event.
+This variable contains the most recent X event.
 
-<H4><A name="fl_event_time">extern ulong fl_event_time</A></H4>
+<A name="fl_event_time"></A> <!-- For old HTML links only ! -->
+extern ulong fl_event_time
 
-<P>This variable contains the time stamp from the most recent X
+This variable contains the time stamp from the most recent X
 event that reported it; not all events do. Many X calls like cut
 and paste need this value.
 
-<H4><A name="fl_xid">Window fl_xid(const Fl_Window *)</A></H4>
+<A name="fl_xid"></A> <!-- For old HTML links only ! -->
+Window fl_xid(const Fl_Window *)
 
-<P>Returns the XID for a window, or zero if not <TT>shown()</TT>.
+Returns the XID for a window, or zero if not <tt>shown()</tt>.
 
-<H4><A name="fl_find">Fl_Window *fl_find(ulong xid)</A></H4>
+<A name="fl_find"></A> <!-- For old HTML links only ! -->
+Fl_Window *fl_find(ulong xid)
 
-<P>Returns the <TT>Fl_Window</TT> that corresponds to the given
-XID, or <TT>NULL</TT> if not found. This function uses a cache
+Returns the <tt>Fl_Window</tt> that corresponds to the given
+XID, or <tt>NULL</tt> if not found. This function uses a cache
 so it is slightly faster than iterating through the windows
-yourself.</P>
+yourself.
 
-<H4><A name="fl_handle">int fl_handle(const XEvent &)</A></H4>
+<A name="fl_handle"></A> <!-- For old HTML links only ! -->
+int fl_handle(const XEvent &)
 
-<P>This call allows you to supply the X events to FLTK, which
+This call allows you to supply the X events to FLTK, which
 may allow FLTK to cooperate with another toolkit or library. The
 return value is non-zero if FLTK understood the event. If the
-window does not belong to FLTK and the <TT>add_handler()</TT>
+window does not belong to FLTK and the <tt>add_handler()</tt>
 functions all return 0, this function will return false.
 
-<P>Besides feeding events your code should call <A
-href="Fl.html#Fl.flush"><TT>Fl::flush()</TT></A>
-periodically so that FLTK redraws its windows.</P>
+Besides feeding events your code should call
+<A href="Fl.html#Fl.flush"><tt>Fl::flush()</tt></A>
+periodically so that FLTK redraws its windows.
 
-<P>This function will call the callback functions. It will not
+This function will call the callback functions. It will not
 return until they complete. In particular, if a callback pops up
-a modal window by calling <A
-href="functions.html#fl_ask"><TT>fl_ask()</TT></A>, for
-instance, it will not return until the modal function
-returns.</P>
+a modal window by calling
+<A href="functions.html#fl_ask"><tt>fl_ask()</tt></A>,
+for instance, it will not return until the modal function
+returns.
 
-<H3>Drawing using Xlib</H3>
+\subsection osissues_drawing_xlib Drawing using Xlib
 
-<P>The following global variables are set before <A
-HREF="subclassing.html#draw"><TT>Fl_Widget::draw()</TT></A> is
-called, or by <A
-href="Fl_Window.html#Fl_Window.make_current"><TT>Fl_Window::make_current()</TT></A>:
+The following global variables are set before
+<A HREF="subclassing.html#draw"><tt>Fl_Widget::draw()</tt></A>
+is called, or by
+<A href="Fl_Window.html#Fl_Window.make_current"><tt>Fl_Window::make_current()</tt></A>:
 
 \code
 extern Display *fl_display;
@@ -113,108 +121,120 @@ extern XVisualInfo *fl_visual;
 extern Colormap fl_colormap;
 \endcode
 
-<P>You must use them to produce Xlib calls.  Don't attempt to change
+You must use them to produce Xlib calls.  Don't attempt to change
 them. A typical X drawing call is written like this:
 
 \code
 XDrawSomething(fl_display, fl_window, fl_gc, ...);
 \endcode
 
-<P>Other information such as the position or size of the X
-window can be found by looking at <A
-href="Fl_Window.html#Fl_Window.make_current"><TT>Fl_Window::current()</TT></A>,
-which returns a pointer to the <TT>Fl_Window</TT> being drawn.
+Other information such as the position or size of the X
+window can be found by looking at
+<A href="Fl_Window.html#Fl_Window.make_current"><tt>Fl_Window::current()</tt></A>,
+which returns a pointer to the <tt>Fl_Window</tt> being drawn.
 
-<H4><A name="fl_xpixel">unsigned long fl_xpixel(Fl_Color i)<BR>
-unsigned long fl_xpixel(uchar r, uchar g, uchar b)</A></H4>
+<A name="fl_xpixel"></A> <!-- For old HTML links only ! -->
+unsigned long fl_xpixel(Fl_Color i) <br>
+unsigned long fl_xpixel(uchar r, uchar g, uchar b)
 
-<P>Returns the X pixel number used to draw the given FLTK color
-index or RGB color. This is the X pixel that <A
-href="drawing.html#fl_color"><TT>fl_color()</TT></A> would use.
+Returns the X pixel number used to draw the given FLTK color
+index or RGB color. This is the X pixel that
+<A href="drawing.html#fl_color"><tt>fl_color()</tt></A> would use.
 
-<H4><A name="fl_parse_color">int fl_parse_color(const char* p, uchar& r, uchar& g, uchar& b)</A></H4>
+<A name="fl_parse_color"></A> <!-- For old HTML links only ! -->
+int fl_parse_color(const char* p, uchar& r, uchar& g, uchar& b)
 
-<P>Convert a name into the red, green, and blue values of a color
+Convert a name into the red, green, and blue values of a color
 by parsing the X11 color names. On other systems, <tt>fl_parse_color</tt>
 can only convert names in hexadecimal encoding, for example <tt>\#ff8083</tt>.
  
-<H4><A name="fl_xfont">extern XFontStruct *fl_xfont</A></H4>
-
-<P>Points to the font selected by the most recent <A
-href="drawing.html#fl_font"><TT>fl_font()</TT></A>. This is not
-necessarily the current font of <TT>fl_gc</TT>, which is not set
-until <A href="drawing.html#text"><TT>fl_draw()</TT></A> is
-called. If FLTK was compiled with Xft support, <TT>fl_xfont</TT>
-will usually be 0 and <TT>fl_xftfont</TT> will contain a pointer 
+<A name="fl_xfont"></A> <!-- For old HTML links only ! -->
+extern XFontStruct *fl_xfont
+
+Points to the font selected by the most recent
+<A href="drawing.html#fl_font"><tt>fl_font()</tt></A>.
+This is not necessarily the current font of <tt>fl_gc</tt>,
+which is not set until
+<A href="drawing.html#text"><tt>fl_draw()</tt></A>
+is called. If FLTK was compiled with Xft support, <tt>fl_xfont</tt>
+will usually be 0 and <tt>fl_xftfont</tt> will contain a pointer 
 to the XftFont structure instead.
 
-<H4><A name="fl_xftfont">extern void *fl_xftfont</A></H4>
+<A name="fl_xftfont"></A> <!-- For old HTML links only ! -->
+extern void *fl_xftfont
 
-<P>If FLTK was compiled with Xft support enabled, <tt>fl_xftfont</tt>
-Points to the xft font selected by the most recent <A
-href="drawing.html#fl_font"><TT>fl_font()</TT></A>. Otherwise 
-it will be 0. <tt>fl_xftfont</tt> should be cast to 
+If FLTK was compiled with Xft support enabled, <tt>fl_xftfont</tt>
+Points to the xft font selected by the most recent
+<A href="drawing.html#fl_font"><tt>fl_font()</tt></A>.
+Otherwise it will be 0. <tt>fl_xftfont</tt> should be cast to 
 <tt>XftFont*</tt>.
 
-<H3>Changing the Display, Screen, or X Visual</H3>
+\subsection osissues_xvisual Changing the Display, Screen, or X Visual
 
-<P>FLTK uses only a single display, screen, X visual, and X
+FLTK uses only a single display, screen, X visual, and X
 colormap. This greatly simplifies its internal structure and
 makes it much smaller and faster. You can change which it uses
 by setting global variables <I>before the first
-<TT>Fl_Window::show()</TT> is called</I>. You may also want to
-call <A href="Fl.html#Fl.visual">Fl::visual()</A>, which is
-a portable interface to get a full color and/or double buffered
+<tt>Fl_Window::show()</tt> is called</I>. You may also want to call
+<A href="Fl.html#Fl.visual">Fl::visual()</A>,
+which is a portable interface to get a full color and/or double buffered
 visual.
 
-<H4><A name="display">int Fl::display(const char *)</A></H4>
+<A name="display"></A> <!-- For old HTML links only ! -->
+int Fl::display(const char *)
 
-<P>Set which X display to use.  This actually does
-<TT>putenv("DISPLAY=...")</TT> so that child programs
-will display on the same screen if called with <TT>exec()</TT>.
+Set which X display to use.  This actually does
+<tt>putenv("DISPLAY=...")</tt> so that child programs
+will display on the same screen if called with <tt>exec()</tt>.
 This must be done before the display is opened. This call is
 provided under MacOS and WIN32 but it has no effect.
 
-<H4><A name="fl_display">extern Display *fl_display</A></H4>
+<A name="fl_display"></A> <!-- For old HTML links only ! -->
+extern Display *fl_display
 
-<P>The open X display. This is needed as an argument to most
-Xlib calls. Don't attempt to change it! This is <TT>NULL</TT>
+The open X display. This is needed as an argument to most
+Xlib calls. Don't attempt to change it! This is <tt>NULL</tt>
 before the display is opened.
 
-<H4><A name="fl_open_display">void fl_open_display()</A></H4>
+<A name="fl_open_display"></A> <!-- For old HTML links only ! -->
+void fl_open_display()
 
-<P>Opens the display. Does nothing if it is already open. This
-will make sure <TT>fl_display</TT> is non-zero. You should call
+Opens the display. Does nothing if it is already open. This
+will make sure <tt>fl_display</tt> is non-zero. You should call
 this if you wish to do X calls and there is a chance that your
-code will be called before the first <TT>show()</TT> of a
+code will be called before the first <tt>show()</tt> of a
 window.
 
-<P>This may call <TT>Fl::abort()</TT> if there is an error
-opening the display.</P>
+This may call <tt>Fl::abort()</tt> if there is an error
+opening the display.
 
-<H4><A name="fl_close_display">void fl_close_display()</A></H4>
+<A name="fl_close_display"></A> <!-- For old HTML links only ! -->
+void fl_close_display()
 
-<P>This closes the X connection. You do <I>not</I> need to call
+This closes the X connection. You do <I>not</I> need to call
 this to exit, and in fact it is faster to not do so! It may be
 useful to call this if you want your program to continue without
 the X connection. You cannot open the display again, and
 probably cannot call any FLTK functions.
 
-<H4><A name="fl_screen">extern int fl_screen</A></H4>
+<A name="fl_screen"></A> <!-- For old HTML links only ! -->
+extern int fl_screen
 
-<P>Which screen number to use. This is set by
-<TT>fl_open_display()</TT> to the default screen. You can change
+Which screen number to use. This is set by
+<tt>fl_open_display()</tt> to the default screen. You can change
 it by setting this to a different value immediately afterwards.
 It can also be set by changing the last number in the
-<TT>Fl::display()</TT> string to "host:0.#".
+<tt>Fl::display()</tt> string to "host:0.#".
 
-<H4><A name="fl_visual">extern XVisualInfo *fl_visual</A><BR>
-<A name="fl_colormap">extern Colormap fl_colormap</A></H4>
+<A name="fl_visual"></A> <!-- For old HTML links only ! -->
+extern XVisualInfo *fl_visual <br>
+<A name="fl_colormap"></A> <!-- For old HTML links only ! -->
+extern Colormap fl_colormap
 
-<P>The visual and colormap that FLTK will use for all windows.
-These are set by <TT>fl_open_display()</TT> to the default
+The visual and colormap that FLTK will use for all windows.
+These are set by <tt>fl_open_display()</tt> to the default
 visual and colormap. You can change them before calling
-<TT>show()</TT> on the first window. Typical code for changing
+<tt>show()</tt> on the first window. Typical code for changing
 the default visual is:
 
 \code
@@ -227,30 +247,30 @@ fl_colormap = make_a_colormap(fl_display, fl_visual->visual, fl_visual->depth);
 window->show(argc, argv);
 \endcode
 
-<H3>Using a Subclass of Fl_Window for Special X Stuff</H3>
+\subsection osissues_specialx Using a Subclass of Fl_Window for Special X Stuff
 
-<P>FLTK can manage an X window on a different screen, visual
+FLTK can manage an X window on a different screen, visual
 and/or colormap, you just can't use FLTK's drawing routines to
-draw into it. But you can write your own <TT>draw()</TT> method
+draw into it. But you can write your own <tt>draw()</tt> method
 that uses Xlib (and/or OpenGL) calls only.
 
-<P>FLTK can also manage XID's provided by other libraries or
+FLTK can also manage XID's provided by other libraries or
 programs, and call those libraries when the window needs to be
-redrawn.</P>
+redrawn.
 
-<P>To do this, you need to make a subclass of <A
-href="Fl_Window.html#Fl_Window"><TT>Fl_Window</TT></A> and
-override some of these virtual functions:</P>
+To do this, you need to make a subclass of
+<A href="Fl_Window.html#Fl_Window"><tt>Fl_Window</tt></A>
+and override some of these virtual functions:
 
-<H4>virtual void Fl_Window::show()</H4>
+virtual void Fl_Window::show()
 
-<P>If the window is already <TT>shown()</TT> this must cause it
+If the window is already <tt>shown()</tt> this must cause it
 to be raised, this can usually be done by calling
-<TT>Fl_Window::show()</TT>. If not <TT>shown()</TT> your
-implementation must call either <TT>Fl_X::set_xid()</TT> or
-<TT>Fl_X::make_xid()</TT>.
+<tt>Fl_Window::show()</tt>. If not <tt>shown()</tt> your
+implementation must call either <tt>Fl_X::set_xid()</tt> or
+<tt>Fl_X::make_xid()</tt>.
 
-<P>An example:</P>
+An example:
 
 \code
 void MyWindow::show() {
@@ -268,44 +288,43 @@ void MyWindow::show() {
 }
 \endcode
 
-<H4>Fl_X *Fl_X::set_xid(Fl_Window *, Window xid)</H4>
+Fl_X *Fl_X::set_xid(Fl_Window *, Window xid)
 
-<P>Allocate a hidden structure called an <TT>Fl_X</TT>, put the
+Allocate a hidden structure called an <tt>Fl_X</tt>, put the
 XID into it, and set a pointer to it from the
-<TT>Fl_Window</TT>. This causes <TT>Fl_Window::shown()</TT> to
+<tt>Fl_Window</tt>. This causes <tt>Fl_Window::shown()</tt> to
 return true.
 
-<H4>void Fl_X::make_xid(Fl_Window *, XVisualInfo *= fl_visual,
-Colormap = fl_colormap)</H4>
+void Fl_X::make_xid(Fl_Window *, XVisualInfo *= fl_visual, Colormap = fl_colormap)
 
-<P>This static method does the most onerous parts of creating an
+This static method does the most onerous parts of creating an
 X window, including setting the label, resize limitations, etc.
-It then does <TT>Fl_X::set_xid()</TT> with this new window and
+It then does <tt>Fl_X::set_xid()</tt> with this new window and
 maps the window.
 
-<H4>virtual void Fl_Window::flush()</H4>
+virtual void Fl_Window::flush()
 
-<P>This virtual function is called by <TT>Fl::flush()</TT> to
+This virtual function is called by <tt>Fl::flush()</tt> to
 update the window. For FLTK's own windows it does this by
-setting the global variables <TT>fl_window</TT> and
-<TT>fl_gc</TT> and then calling the <TT>draw()</TT> method.  For
+setting the global variables <tt>fl_window</tt> and
+<tt>fl_gc</tt> and then calling the <tt>draw()</tt> method.  For
 your own windows you might just want to put all the drawing code
 in here.
 
-<P>The X region that is a combination of all <TT>damage()</TT>
-calls done so far is in <TT>Fl_X::i(this)->region</TT>. If
-<TT>NULL</TT> then you should redraw the entire window. The
-undocumented function <TT>fl_clip_region(XRegion)</TT> will
-initialize the FLTK clip stack with a region or <TT>NULL</TT>
-for no clipping. You must set region to <TT>NULL</TT> afterwards
-as <TT>fl_clip_region()</TT> will own and delete it when
-done.</P>
+The X region that is a combination of all <tt>damage()</tt>
+calls done so far is in <tt>Fl_X::i(this)->region</tt>. If
+<tt>NULL</tt> then you should redraw the entire window. The
+undocumented function <tt>fl_clip_region(XRegion)</tt> will
+initialize the FLTK clip stack with a region or <tt>NULL</tt>
+for no clipping. You must set region to <tt>NULL</tt> afterwards
+as <tt>fl_clip_region()</tt> will own and delete it when
+done.
 
-<P>If <TT>damage() & FL_DAMAGE_EXPOSE</TT> then only X
+If <tt>damage() & FL_DAMAGE_EXPOSE</tt> then only X
 expose events have happened. This may be useful if you have an
-undamaged image (such as a backing buffer) around.</P>
+undamaged image (such as a backing buffer) around.
 
-<P>Here is a sample where an undamaged image is kept somewhere:</P>
+Here is a sample where an undamaged image is kept somewhere:
 
 \code
 void MyWindow::flush() {
@@ -316,12 +335,12 @@ void MyWindow::flush() {
 }
 \endcode
 
-<H4>virtual void Fl_Window::hide()</H4>
+virtual void Fl_Window::hide()
 
-<P>Destroy the window server copy of the window. Usually you
+Destroy the window server copy of the window. Usually you
 will destroy contexts, pixmaps, or other resources used by the
-window, and then call <TT>Fl_Window::hide()</TT> to get rid of
-the main window identified by <TT>xid()</TT>. If you override
+window, and then call <tt>Fl_Window::hide()</tt> to get rid of
+the main window identified by <tt>xid()</tt>. If you override
 this, you must also override the destructor as shown:
 
 \code
@@ -334,11 +353,11 @@ void MyWindow::hide() {
 }
 \endcode
 
-<H4>virtual void Fl_Window::~Fl_Window()</H4>
+virtual void Fl_Window::~Fl_Window()
 
-<P>Because of the way C++ works, if you override <TT>hide()</TT>
+Because of the way C++ works, if you override <tt>hide()</tt>
 you <I>must</I> override the destructor as well (otherwise only
-the base class <TT>hide()</TT> is called):
+the base class <tt>hide()</tt> is called):
 
 \code
 MyWindow::~MyWindow() {
@@ -346,15 +365,15 @@ MyWindow::~MyWindow() {
 }
 \endcode
 
-<H3>Setting the Icon of a Window</H3>
+\subsection osissues_x_icon Setting the Icon of a Window
 
-<P>FLTK currently supports setting a window's icon <b>before</b> it
-is shown using the <TT>Fl_Window::icon()</TT> method.
+FLTK currently supports setting a window's icon <b>before</b> it
+is shown using the <tt>Fl_Window::icon()</tt> method.
 
-<H4>void Fl_Window::icon(char *)</H4>
+void Fl_Window::icon(char *)
 
-<P>Sets the icon for the window to the passed pointer. You will
-need to cast the icon <TT>Pixmap</TT> to a <TT>char *</TT> when
+Sets the icon for the window to the passed pointer. You will
+need to cast the icon <tt>Pixmap</tt> to a <tt>char *</tt> when
 calling this method. To set a monochrome icon using a bitmap compiled
 with your application use:
 
@@ -369,7 +388,7 @@ Pixmap p = XCreateBitmapFromData(fl_display, DefaultRootWindow(fl_display),
 window->icon((char *)p);
 \endcode
 
-<P>To use a multi-colored icon, the XPM format and library
+To use a multi-colored icon, the XPM format and library
 should be used as follows:
 
 \code
@@ -386,122 +405,122 @@ XpmCreatePixmapFromData(fl_display, DefaultRootWindow(fl_display),
 window->icon((char *)p);
 \endcode
 
-<p>When using the Xpm library, be sure to include it in the list
-of libraries that are used to link the application (usually
-"-lXpm").</p>
+When using the Xpm library, be sure to include it in the list
+of libraries that are used to link the application (usually "-lXpm").
 
-<CENTER><TABLE WIDTH="90%" BORDER="1" CELLPADDING="5" CELLSPACING="0" BGCOLOR="#cccccc">
+<CENTER>
+<TABLE WIDTH="90%" BORDER="1" CELLPADDING="5" CELLSPACING="0" BGCOLOR="#cccccc">
 <TR>
 	<TD><B>NOTE:</B>
 	
-	<P>You must call <A
-	HREF="Fl_Window.html#Fl_Window.show"><TT>Fl_Window::show(argc,
-	argv)</TT></A> for the icon to be used. The
-	<TT>Fl_Window::show()</TT> method does not bind the icon
+	You must call <A
+	HREF="Fl_Window.html#Fl_Window.show"><tt>Fl_Window::show(argc,
+	argv)</tt></A> for the icon to be used. The
+	<tt>Fl_Window::show()</tt> method does not bind the icon
 	to the window.
 
 	</TD>
 </TR>
-</TABLE></CENTER>
+</TABLE>
+</CENTER>
 
-<H3>X Resources</H3>
+\subsection osissues_xresources X Resources
 
-<P>When the <A
-HREF="Fl_Window.html#Fl_Window.show"><TT>Fl_Window::show(argc,
-argv)</TT></A> method is called, FLTK looks for the following X
-resources:
+When the
+<A HREF="Fl_Window.html#Fl_Window.show"><tt>Fl_Window::show(argc, argv)</tt></A>
+method is called, FLTK looks for the following X resources:
 
-<UL>
-
-	<LI><TT>background</TT> - The default background color
+\li <tt>background</tt> - The default background color
 	for widgets (color).
 
-	<LI><TT>dndTextOps</TT> - The default setting for
+\li <tt>dndTextOps</tt> - The default setting for
 	drag and drop text operations (boolean).
 
-	<LI><TT>foreground</TT> - The default foreground (label)
+\li <tt>foreground</tt> - The default foreground (label)
 	color for widgets (color).
 
-	<LI><TT>scheme</TT> - The default scheme to use
-	(string).
+\li <tt>scheme</tt> - The default scheme to use (string).
 
-	<LI><TT>selectBackground</TT> - The default selection
+\li <tt>selectBackground</tt> - The default selection
 	color for menus, etc. (color).
 
-	<LI><TT>Text.background</TT> - The default background
+\li <tt>Text.background</tt> - The default background
 	color for text fields (color).
 
-	<LI><TT>tooltips</TT> - The default setting for
+\li <tt>tooltips</tt> - The default setting for
 	tooltips (boolean).
 
-	<LI><TT>visibleFocus</TT> - The default setting for
+\li <tt>visibleFocus</tt> - The default setting for
 	visible keyboard focus on non-text widgets (boolean).
 
-</UL>
-
-<P>Resources associated with the first window's <A
-HREF="Fl_Window.html#Fl_Window.xclass"><TT>Fl_Window::xclass()</TT></A>
+Resources associated with the first window's
+<A HREF="Fl_Window.html#Fl_Window.xclass"><tt>Fl_Window::xclass()</tt></A>
 string are queried first, or if no class has been specified then
-the class "fltk" is used (e.g. <TT>fltk.background</TT>). If no
+the class "fltk" is used (e.g. <tt>fltk.background</tt>). If no
 match is found, a global search is done (e.g.
-<TT>*background</TT>).
+<tt>*background</tt>).
 
-<H2>The Windows (WIN32) Interface</H2>
+\section osissues_win32 The Windows (WIN32) Interface
 
-<P>The Windows interface provides access to the WIN32 GDI
+The Windows interface provides access to the WIN32 GDI
 state information and data structures.
 
-<H3>Handling Other WIN32 Messages</H3>
+\subsection osissues_win32_messages Handling Other WIN32 Messages
 
-<P>By default a single WNDCLASSEX called "FLTK" is
-created. All <TT>Fl_Window</TT>'s are of this class unless you
-use <TT>Fl_Window::xclass()</TT>. The window class is created
-the first time <TT>Fl_Window::show()</TT> is called.
+By default a single WNDCLASSEX called "FLTK" is
+created. All <tt>Fl_Window</tt>'s are of this class unless you
+use <tt>Fl_Window::xclass()</tt>. The window class is created
+the first time <tt>Fl_Window::show()</tt> is called.
 
-<P>You can probably combine FLTK with other libraries that make
+You can probably combine FLTK with other libraries that make
 their own WIN32 window classes. The easiest way is to call
-<TT>Fl::wait()</TT>, as it will call <TT>DispatchMessage</TT>
+<tt>Fl::wait()</tt>, as it will call <tt>DispatchMessage</tt>
 for all messages to the other windows. If necessary you can let
 the other library take over as long as it calls
-<TT>DispatchMessage()</TT>, but you will have to arrange for the
-function <TT>Fl::flush()</TT> to be called regularly so that
+<tt>DispatchMessage()</tt>, but you will have to arrange for the
+function <tt>Fl::flush()</tt> to be called regularly so that
 widgets are updated, timeouts are handled, and the idle
-functions are called.</P>
+functions are called.
 
-<H4><A name="fl_msg">extern MSG fl_msg</A></H4>
+<A name="fl_msg"></A> <!-- For old HTML links only ! -->
+extern MSG fl_msg
 
-<P>This variable contains the most recent message read by
-<TT>GetMessage</TT>, which is called by <A
-href="Fl.html#Fl.wait"><TT>Fl::wait()</TT></A>. This may not be the
+This variable contains the most recent message read by
+<tt>GetMessage</tt>, which is called by <A
+href="Fl.html#Fl.wait"><tt>Fl::wait()</tt></A>. This may not be the
 most recent message sent to an FLTK window, because silly WIN32
 calls the handle procedures directly for some events (sigh).
 
-<H4><A name="WIN32.add_handler">void Fl::add_handler(int (*f)(int))</A></H4>
+<A name="WIN32.add_handler"></A> <!-- For old HTML links only ! -->
+void Fl::add_handler(int (*f)(int))
 
-<P>Installs a function to parse unrecognized messages sent to
+Installs a function to parse unrecognized messages sent to
 FLTK windows. If FLTK cannot figure out what to do with a
 message, it calls each of these functions (most recent first)
 until one of them returns non-zero. The argument passed to the
 functions is the FLTK event that was not handled or zero for
 unknown messages. If all the handlers return zero then FLTK
-calls <TT>DefWindowProc()</TT>.
+calls <tt>DefWindowProc()</tt>.
 
-<H4><A name="WIN32.fl_xid">HWND fl_xid(const Fl_Window *)</A></H4>
+<A name="WIN32.fl_xid"></A> <!-- For old HTML links only ! -->
+HWND fl_xid(const Fl_Window *)
 
-<P>Returns the window handle for a <TT>Fl_Window</TT>, or zero
-if not <TT>shown()</TT>.
+Returns the window handle for a <tt>Fl_Window</tt>, or zero
+if not <tt>shown()</tt>.
 
-<H4><A name="WIN32.fl_find">Fl_Window *fl_find(HWND xid)</A></H4>
+<A name="WIN32.fl_find"></A> <!-- For old HTML links only ! -->
+Fl_Window *fl_find(HWND xid)
 
-<P>Returns the <TT>Fl_Window</TT> that corresponds to the given
-window handle, or <TT>NULL</TT> if not found. This function uses
+Returns the <tt>Fl_Window</tt> that corresponds to the given
+window handle, or <tt>NULL</tt> if not found. This function uses
 a cache so it is slightly faster than iterating through the
 windows yourself.
 
-<H3><A name="WIN32.gdi">Drawing Things Using the WIN32 GDI</A></H3>
+<A name="WIN32.gdi"></A> <!-- For old HTML links only ! -->
+\subsection osissues_win32_gdi Drawing Things Using the WIN32 GDI
 
-<P>When the virtual function <A
-HREF="subclassing.html#draw"><TT>Fl_Widget::draw()</TT></A> is
+When the virtual function
+<A HREF="subclassing.html#draw"><tt>Fl_Widget::draw()</tt></A> is
 called, FLTK stores all the silly extra arguments you need to
 make a proper GDI call in some global variables:
 
@@ -514,12 +533,11 @@ HPEN fl_pen();
 HBRUSH fl_brush();
 \endcode
 
-<P>These global variables are set before <TT>draw()</TT> is
-called, or by <A
-href="Fl_Window.html#Fl_Window.make_current"><TT>Fl_Window::make_current()</TT></A>.
+These global variables are set before <tt>draw()</tt> is called, or by
+<A href="Fl_Window.html#Fl_Window.make_current"><tt>Fl_Window::make_current()</tt></A>.
 You can refer to them when needed to produce GDI calls, but don't
 attempt to change them. The functions return GDI objects for
-the current color set by <TT>fl_color()</TT> and are created as
+the current color set by <tt>fl_color()</tt> and are created as
 needed and cached. A typical GDI drawing call is written like
 this:
 
@@ -527,19 +545,19 @@ this:
 DrawSomething(fl_gc, ..., fl_brush());
 \endcode
 
-<P>It may also be useful to refer to <A
-href="Fl_Window.html#Fl_Window.make_current"><TT>Fl_Window::current()</TT></A>
+It may also be useful to refer to
+<A href="Fl_Window.html#Fl_Window.make_current"><tt>Fl_Window::current()</tt></A>
 to get the window's size or position.
 
-<H3>Setting the Icon of a Window</H3>
+\subsection osissues_icon_windows Setting the Icon of a Window
 
-<P>FLTK currently supports setting a window's icon *before* it
-is shown using the <TT>Fl_Window::icon()</TT> method.
+FLTK currently supports setting a window's icon *before* it
+is shown using the <tt>Fl_Window::icon()</tt> method.
 
-<H4>void Fl_Window::icon(char *)</H4>
+void Fl_Window::icon(char *)
 
-<P>Sets the icon for the window to the passed pointer. You will
-need to cast the <TT>HICON</TT> handle to a <TT>char *</TT> when
+Sets the icon for the window to the passed pointer. You will
+need to cast the <tt>HICON</tt> handle to a <tt>char *</tt> when
 calling this method. To set the icon using an icon resource
 compiled with your application use:
 
@@ -547,55 +565,55 @@ compiled with your application use:
 window->icon((char *)LoadIcon(fl_display, MAKEINTRESOURCE(IDI_ICON)));
 \endcode
 
-<P>You can also use the <TT>LoadImage()</TT> and related
+You can also use the <tt>LoadImage()</tt> and related
 functions to load specific resolutions or create the icon from
 bitmap data.
 
-<CENTER><TABLE WIDTH="90%" BORDER="1" CELLPADDING="5" CELLSPACING="0" BGCOLOR="#cccccc">
+<CENTER>
+<TABLE WIDTH="90%" BORDER="1" CELLPADDING="5" CELLSPACING="0" BGCOLOR="#cccccc">
 <TR>
 	<TD><B>NOTE:</B>
 	
-	<P>You must call <A
-	HREF="Fl_Window.html#Fl_Window.show"><TT>Fl_Window::show(argc,
-	argv)</TT></A> for the icon to be used. The
-	<TT>Fl_Window::show()</TT> method does not bind the icon
+	You must call <A
+	HREF="Fl_Window.html#Fl_Window.show"><tt>Fl_Window::show(argc,
+	argv)</tt></A> for the icon to be used. The
+	<tt>Fl_Window::show()</tt> method does not bind the icon
 	to the window.
 
 	</TD>
 </TR>
-</TABLE></CENTER>
+</TABLE>
+</CENTER>
 
-<H3>How to Not Get a MSDOS Console Window</H3>
+\subsection osissues_msdos_console How to Not Get a MSDOS Console Window
 
-<P>WIN32 has a really stupid mode switch stored in the
+WIN32 has a really stupid mode switch stored in the
 executables that controls whether or not to make a console
 window.
 
-<P>To always get a console window you simply create a console
+To always get a console window you simply create a console
 application (the "/SUBSYSTEM:CONSOLE" option for the
 linker). For a GUI-only application create a WIN32 application
-(the "/SUBSYSTEM:WINDOWS" option for the linker).</P>
+(the "/SUBSYSTEM:WINDOWS" option for the linker).
 
-<P>FLTK includes a <TT>WinMain()</TT> function that calls the
-ANSI standard <TT>main()</TT> entry point for you. <I>This
+FLTK includes a <tt>WinMain()</tt> function that calls the
+ANSI standard <tt>main()</tt> entry point for you. <I>This
 function creates a console window when you use the debug version
-of the library.</I></P>
+of the library.</I>
 
-<P>WIN32 applications without a console cannot write to
-<TT>stdout</TT> or <TT>stderr</TT>, even if they are run from a
+WIN32 applications without a console cannot write to
+<tt>stdout</tt> or <tt>stderr</tt>, even if they are run from a
 console window. Any output is silently thrown away.
 Additionally, WIN32 applications are run in the background by
 the console, although you can use "start /wait program" to run
-them in the foreground.</P>
+them in the foreground.
 
-<H3>Known WIN32 Bugs and Problems</H3>
+\subsection osissues_win32_problems Known WIN32 Bugs and Problems
 
-<P>The following is a list of known bugs and problems in the WIN32
+The following is a list of known bugs and problems in the WIN32
 version of FLTK:
 
-<UL>
-
-	<LI>If a program is deactivated, <TT>Fl::wait()</TT>
+\li	If a program is deactivated, <tt>Fl::wait()</tt>
 	does not return until it is activated again, even though
 	many events are delivered to the program. This can cause
 	idle background processes to stop unexpectedly. This
@@ -604,138 +622,136 @@ version of FLTK:
 	forced to remove most of the efficiency FLTK uses for
 	redrawing in order to get windows to update while being
 	moved. This is a design error in WIN32 and probably
-	impossible to get around.</LI>
+	impossible to get around.
 
-	<LI><TT>Fl_Gl_Window::can_do_overlay()</TT> returns true
+\li	<tt>Fl_Gl_Window::can_do_overlay()</tt> returns true
 	until the first time it attempts to draw an overlay, and
 	then correctly returns whether or not there is overlay
-	hardware.</LI>
+	hardware.
 
-	<LI><TT>SetCapture</TT> (used by <TT>Fl::grab()</TT>)
+\li	<tt>SetCapture</tt> (used by <tt>Fl::grab()</tt>)
 	doesn't work, and the main window title bar turns gray
-	while menus are popped up.</LI>
+	while menus are popped up.
 
-	<LI>Compilation with <TT>gcc 3.4.4</TT> and <TT>-Os</TT> exposes an
+\li	Compilation with <tt>gcc 3.4.4</tt> and <tt>-Os</tt> exposes an
 	optimisation bug in gcc. The symptom is that when drawing
 	filled circles only the perimeter is drawn. This can for instance
 	be seen in the symbols demo. Other optimisation options such
 	as -O2 and -O3 seem to work OK. More details can be found
-	in STR#1656 </LI>
-</UL>
+	in STR#1656
 
-<H2>The MacOS Interface</h2>
+\subject osissues_macos The MacOS Interface
 
-<P>FLTK supports MacOS X using the Apple Carbon library. Older
+FLTK supports MacOS X using the Apple Carbon library. Older
 versions of MacOS are <I>not</I> supported.
 
-<H4>Control, Option, and Command Modifier Keys</H4>
+\par Control, Option, and Command Modifier Keys
 
-<P>FLTK maps the Mac 'control' key to <TT>FL_CTRL</TT>, the
-'option' key to <TT>FL_ALT</TT> and the 'Apple' key to
-<TT>FL_META</TT>. Keyboard events return the key name in
-<TT>Fl::event_key()</TT> and the keystroke translation in
-<TT>Fl::event_text()</TT>. For example, typing Option-Y on a Mac
-keyboard will set <TT>FL_ALT</TT> in <TT>Fl::event_state()</TT>,
-set <TT>Fl::event_key()</TT> to 'y' and return the Yen symbol in
-<TT>Fl::event_text()</TT>.
+FLTK maps the Mac 'control' key to <tt>FL_CTRL</tt>, the
+'option' key to <tt>FL_ALT</tt> and the 'Apple' key to
+<tt>FL_META</tt>. Keyboard events return the key name in
+<tt>Fl::event_key()</tt> and the keystroke translation in
+<tt>Fl::event_text()</tt>. For example, typing Option-Y on a Mac
+keyboard will set <tt>FL_ALT</tt> in <tt>Fl::event_state()</tt>,
+set <tt>Fl::event_key()</tt> to 'y' and return the Yen symbol in
+<tt>Fl::event_text()</tt>.
 
-<H4>WindowRef fl_xid(const Fl_Window *)</H4>
+WindowRef fl_xid(const Fl_Window *)
 
-<P>Returns the window reference for an <tt>Fl_Window</tt>, or
-<TT>NULL</TT> if the window has not been shown.
+Returns the window reference for an <tt>Fl_Window</tt>, or
+<tt>NULL</tt> if the window has not been shown.
 
-<h4>Fl_Window *fl_find(WindowRef xid)</h4>
+Fl_Window *fl_find(WindowRef xid)
 
-<P>Returns the <tt>Fl_Window</tt> that corresponds to the give
-window handle, or <TT>NULL</TT> if not found. FLTK windows that
+Returns the <tt>Fl_Window</tt> that corresponds to the give
+window handle, or <tt>NULL</tt> if not found. FLTK windows that
 are children of top-level windows share the WindowRef of the
 top-level window.
 
-<h3>Apple "Quit" Event</h3>
+\subsection osissues_apple_quit Apple "Quit" Event
 
-<P>When the user press Cmd-Q or requests a termination of the
+When the user press Cmd-Q or requests a termination of the
 application, OS X will send a "Quit" Apple Event. FLTK handles
 this event by sending an <tt>FL_CLOSE</tt> event to all open
 windows. If all windows close, the application will terminate.
 
-<h3>Apple "Open" Event</h3>
+\subsection osissues_apple_open Apple "Open" Event
 
 Whenever the user drops a file onto an application icon, OS X
 generates an Apple Event of the type "Open". You can have FLTK
 notify you of an Open event by setting the <tt>fl_open_callback</tt>.
 
-<h4><a name=fl_open_callback>void fl_open_callback(void (*cb)(const char *))</a></h4>
+<a name="fl_open_callback"></A> <!-- For old HTML links only ! -->
+void fl_open_callback(void (*cb)(const char *))
 
 <tt>cb</tt> will be called with a single iUnix-style file name and path.
 If multiple files were dropped, <tt>fl_open_callback</tt> will be called
 multiple times.
 
-<h3>Drawing Things Using QuickDraw</h3>
+\subsection osissues_quickdraw Drawing Things Using QuickDraw
 
-<P>When the virtual function <tt>Fl_Widget::draw()</tt> is
+When the virtual function <tt>Fl_Widget::draw()</tt> is
 called, FLTK has prepared the Window and CGrafPort for drawing.
 Clipping and offsets are prepared to allow correct subwindow
 drawing.
 
-<h3>Drawing Things Using Quartz</h3>
+\subsection osissues_quartz Drawing Things Using Quartz
 
-<P>If the FLTK library was compiled using the configuration
+If the FLTK library was compiled using the configuration
 flag <tt>--enable-quartz</tt>, all code inside <tt>Fl_Widget::draw()</tt>
 is expected to call Quartz drawing functions instead of 
 QuickDraw. The Quartz coordinate system is flipped to match
 FLTK's coordinate system. The origin for all drawing is in the top
 left corner of the enclosing <tt>Fl_Window</tt>.
 
-<h3>Fl_Double_Window</h3>
+Fl_Double_Window
 
-<P>OS X double-buffers all windows automatically. On OS X,
+OS X double-buffers all windows automatically. On OS X,
 <tt>Fl_Window</tt> and <tt>Fl_Double_Window</tt> are handled
 internally in the same way.
 
-<h3>Mac File System Specifics</h3>
+\subsection osissues_mac_files Mac File System Specifics
 
-<h4>Resource Forks</h4>
+\par Resource Forks
 
-<P>FLTK does not access the resource fork of an application.
+FLTK does not access the resource fork of an application.
 However, a minimal resource fork must be created for OS X
 applications
 
-<CENTER><TABLE WIDTH="80%" BORDER="1" BGCOLOR="#cccccc" CELLPADDING="5">
+<CENTER>
+<TABLE WIDTH="80%" BORDER="1" BGCOLOR="#cccccc" CELLPADDING="5">
 <TR><TD><B>Caution:</B>
 
-<P>When using UNIX commands to copy or move executables, OS X
+When using UNIX commands to copy or move executables, OS X
 will NOT copy any resource forks! For copying and moving use
 CpMac and MvMac respectively. For creating a tar archive, all
 executables need to be stripped from their Resource Fork before
 packing, e.g. "DeRez fluid > fluid.r". After unpacking the
 Resource Fork needs to be reattached, e.g. "Rez fluid.r -o
 fluid".
-</TD></TR></TABLE></CENTER>
+</TD></TR></TABLE>
+</CENTER>
 
-<P>It is advisable to use the Finder for moving and copying and
+It is advisable to use the Finder for moving and copying and
 Mac archiving tools like Sit for distribution as they will
 handle the Resource Fork correctly. 
 
-<h4>Mac File Paths</h4>
+\par Mac File Paths
 
-<P>FLTK uses UNIX-style filenames and paths.
+FLTK uses UNIX-style filenames and paths.
 
-<H3>Known MacOS Bugs and Problems</H3>
+\subsection osissues_macos_problems Known MacOS Bugs and Problems
 
-<P>The following is a list of known bugs and problems in the
+The following is a list of known bugs and problems in the
 MacOS version of FLTK:
 
-<UL>
+\li	Line styles are not well supported. This is due to
+	limitations in the QuickDraw interface.
 
-	<LI>Line styles are not well supported. This is due to
-	limitations in the QuickDraw interface.</LI>
-
-	<li>Nested subwindows are not supported, i.e. you can
+\li	Nested subwindows are not supported, i.e. you can
 	have a <tt>Fl_Window</tt> widget inside a
 	<tt>Fl_Window</tt>, but not a <tt>Fl_Window</tt> inside a
-	<tt>Fl_Window</tt> inside a <tt>Fl_Window</tt>.</li>
-
-</UL>
+	<tt>Fl_Window</tt> inside a <tt>Fl_Window</tt>.
 
 <hr>
 <a class="el" href="index.html">[Index]</a> &nbsp;&nbsp;