If I use the <pre> tag in my wxHtmlWindow without closing it, the window shows the entire dataset twice; once under the effects of the <pre> tag, and once without.
simple example: output.AppendToPage("""<pre>test""")
I get this showing 'test' twice, once in fixed-width font, once in proportional. Obviously I only want it to display once, in fixed-width font.
i) Is this a known bug?
ii) Is there a workaround for fixed-width text in wxHtmlWindow? The <font> tag with the Face attribute doesn't work, and the <tt> tag doesn't either.
iii) If not, is there any alternative to wxHtmlWindow? I don't think the Scintilla-based control will be any good because I need to be able to use arbitrary combinations of foreground and background colours, rather than a fixed number of styles.
···
--
Ben Sizer
http://pages.eidosnet.co.uk/kylotan
Hi,
Ben Sizer wrote:
If I use the <pre> tag in my wxHtmlWindow without closing it
Although wxHTML's behaviour is arguably weird here, it's not really a
bug because the input is not valid HTML markup:
"""
9.3.4 Preformatted text: The PRE element
......
Start tag: required, End tag: required
""" (from HTML 4.01 spec at
http://www.w3.org/TR/html4/struct/text.html#edef-PRE)
Having said that, it would be nice if wxHTML behaved better in this
case, but working on correct input bugs has higher priority. wxHTML
should behave correctly if fix your HTML files to close <pre> content
with </pre>.
ii) Is there a workaround for fixed-width text in wxHtmlWindow? The
<font> tag with the Face attribute doesn't work, and the <tt> tag
doesn't either.
Both of them work here, what exactly do you mean by "doesn't work"? On
what platform and in what situation?
Regards,
Vaclav
···
--
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x465264C9
Vaclav Slavik wrote:
If I use the <pre> tag in my wxHtmlWindow without closing it
Although wxHTML's behaviour is arguably weird here, it's not really a bug because the input is not valid HTML markup:
I know it's not valid, but that restriction makes the control unusable for a lot of applications. What if you're downloading a file, appending to it as you go along... is it going to show something totally wrong until you finally add the final </HTML> tag? It should really work with whatever it's got and assume that the tags will close in reverse order. Otherwise it's useless for progressively rendering a page.
ii) Is there a workaround for fixed-width text in wxHtmlWindow? The <font> tag with the Face attribute doesn't work, and the <tt> tag doesn't either.
Both of them work here, what exactly do you mean by "doesn't work"?
It simply continues to show the text in the default font.
On what platform and in what situation?
Windows 98SE. There is no 'situation' to talk of really - I just add text to the window and it doesn't display correctly.
···
--
Ben Sizer
http://pages.eidosnet.co.uk/kylotan
Hi,
Ben Sizer wrote:
I know it's not valid, but that restriction makes the control
unusable for a lot of applications. What if you're downloading a
file, appending to it as you go along...
That's the problem, wxHTML is lightweight, simple HTML renderer that
isn't supposed to be used like this. Writing forgiving HTML
interpreter is much harder that writing strict one.
It should really work with whatever it's got and assume that
the tags will close in reverse order.
It's a matter of personal opinion, really: you say it should work with
whatever you pass it (even though it isn't defined anywhere what to
do with garbage), I say you should provide valid input.
Otherwise it's useless for
progressively rendering a page.
That's true. OTOH it was never meant to do anything like that. I
forgot to mention it in my previous reply, but you may want to look
at wxMozilla project -- IIRC Mozilla can display the pages
progressively and it is certainly much better equipped for dealing
with broken markup.
> On what platform and in what situation?
Windows 98SE. There is no 'situation' to talk of really -
Like if the font exists on your system in the encoding used by that
HTML file, if the font specification is correct, if the case of font
name matches that of installed font (bugs related to this should be
fixed already, but there may be something that I overlooked), if you
set the fonts yourself using wxHtmlWindow.SetFonts or not, that kind
of information.
Regards,
Vaclav
···
--
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x465264C9
Ben Sizer wrote:
>>ii) Is there a workaround for fixed-width text in wxHtmlWindow? The
>><font> tag with the Face attribute doesn't work, and the <tt> tag
>>doesn't either.
>
> Both of them work here, what exactly do you mean by "doesn't work"?
It simply continues to show the text in the default font.
I had this problem, and it turned out that wxHtmlWindow was case
sensitive:
<TT> worked, while<tt> didn't. This is a bug, but I never got around to
reporting it, as I had complete control of my html anyway.
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
Hi,
Chris Barker wrote:
I had this problem, and it turned out that wxHtmlWindow was case
sensitive:
No, it isn't (never was). It had to be something else, because all
tags are converted to uppercase before the parser can see them. A
possible explanation is that wxToupper() (which is same as toupper()
C function in ANSI mode) didn't work, but I can't imagine any
situation when this would the case...
Vaclav
···
--
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x465264C9