 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <MPG.17017ad24611f7c09896ef@news.povray.org>, lpv### [at] gmx de
says...
> If you write <b></b><b/>word</b>, should the user agent render the first
That should be <b></b><b>word</b> of course.
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 19 Mar 2002 16:42:29 +0100, Lutz-Peter Hooge <lpv### [at] gmxde> wrote:
> > "The BR element forcibly breaks (ends) the current line of text."
> > But what it should do when there is a break by <BR> already ?
>
> But IMO breaking a line also creates a new (empty) line.
line _of text_ ?
> This is how it works everywere else, and the specification doesn't say
> in HTML it should behave different.
I know only one popular markup language used to specify hierarchy of documents
so I can't compare. Putting one line break is important for text
hierarchy/meaning. Putting two line breaks is text formatting and text
formatting isn't part of document herarchy so no need to aware about formating
behaviour (It's just an idea of explanation - i'm also confused).
> And last: all browsers (at least those I have here) do interpret multiple
> BR's as expected. IE does it too, except if inside a PRE block.
Yes, that's the hint it can be a bug. But we can't be sure. Anyway I again
suggest different line break handling. In particular simple "\n" is valid in
<pre> and even use less bits of transfer :-)
> So I hope it will now work correctly everywere.
"The page you are looking for is currently unavailable. The Web site might be
experiencing technical difficulties, or you may need to adjust your browser
settings." :-(
> If you write <b></b><b/>word</b>, should the user agent render the first
> B block (containing zero characters) bold, or just skip it? ;-)
No. The error should be delivered by mail to designer ;-)
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <m8ne9ussrad7im0bagk2kt0fipepfjtpph@4ax.com>, abx### [at] babilonorg
says...
> hierarchy/meaning. Putting two line breaks is text formatting and text
> formatting isn't part of document herarchy
That is a point.
But I really think, if multiple br's were supposed to be ignored, than
specification would explicitly say that, like it does for <p>.
> Anyway I again
> suggest different line break handling. In particular simple "\n" is valid in
> <pre> and even use less bits of transfer :-)
Now, that I took that out, you want it back ;-)
No, the reason why I originally used <br>'s instead of \n inside a <pre>
block was that Netscape 4 ocassionly ignored the \n, I assume it was
confused by the <span> elements, but these are needed for the
highlighting...
I really think the way it is now is the cleanest and most compatible.
If someone actually finds a (not too exotic) browser that doesn't like
the line breaks as they are now, I'll replace it with <br>
But I really don't want to add a space where there wasn't one in the
original source, unless it really is necessary.
> "The page you are looking for is currently unavailable. The Web site might be
> experiencing technical difficulties, or you may need to adjust your browser
> settings." :-(
Unfortunately there's nothing I could do about that (but here it works).
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"ingo" <ing### [at] homenl <mailto:ing### [at] homenl>> wrote in message
<news:Xns### [at] povrayorg>...
> It does not deal with nested multiline comments in the right way.
What do you mean "the right way"? It seems that POV doesn't support nested
multiline comments.
Example, please, if possible.
> It has problems with a < preceded by a comma (no coloration)
Thanks, should be a bug.
> It has sometimes problems with the {}
Example, please, if possible.
I also have found one - "\"" is not handling correctly.
Thank you for testing.
>It all works now:
><http://members.home.nl/seedseven/povsdl2html.py>
That's always fine to have alternatives :)
I hope this option will be in POV.
Regards,
Gleb
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c988556@news.povray.org>, "Gleb" <gk1### [at] sotonacuk> wrote:
> What do you mean "the right way"? It seems that POV doesn't support nested
> multiline comments.
Actually, it does. With this:
/*
Part 1
/*
Part 2
*/
Part 3
*/
The whole thing, from Part 1 to Part 3 is a comment. It is a little more
difficult to handle than the C/C++ way, which cheats by not allowing
nested comments, but it is much more convenient when commenting out big
blocks of code that are documented with comments. The syntax coloring in
the editor might mess it up though.
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:3c988556@news.povray.org Gleb wrote:
>> It does not deal with nested multiline comments in the right way.
> What do you mean "the right way"? It seems that POV doesn't support
> nested multiline comments.
Ah, I assumed that because the POV-Ray parser deals with nested multi-
line comments the code coloring would do also. Wrong assumption. Yet I
think it is more elegant when colorizer deals with it.
>> It has sometimes problems with the {}
> Example, please, if possible.
Try the piece of code below. It produces black {} inside the macro. It
produces black }{ after T_Wood7 and T_Wood14.
---%<------%<---
#macro Ring (Rin,Rout,Height)
difference {
cylinder {<0,(-Height/2),0>,<0,Height/2,0>, Rout}
cylinder {<0,(-Height/1.99),0>,<0,Height/1.99,0>, Rin}
}
#end //macro
texture {T_Wood7}
normal {
wood 0.03
scale <0.075, 0.075, 1>
turbulence 0.065
omega 0.45
lambda 2.3
rotate x*4
}
merge {
difference {
object {
Ring(0.561,0.59,0.3)
rotate <0,0,90>
}
box{<-1.2,-1,-1>,<1.2,0,1>}
box{<-1.2,-1,-1>,<1.2,1,0>}
}
box{<-0.15,0.56,-0.8>,<0.15,0.59,0>}
translate <0.95,0,0>
texture {T_Wood14}
}
merge {
difference {
object {
Ring(0.561,0.59,0.3)
rotate <0,0,90>
}
box{<-1.2,-1,-1>,<1.2,0,1>}
box{<-1.2,-1,-1>,<1.2,1,0>}
}
box{<-0.15,0.56,-0.8>,<0.15,0.59,0>}
translate <-0.95,0,0>
texture {T_Wood14}
}
---%<------%<---
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"ingo" <ing### [at] homenl> wrote in message
news:Xns### [at] povrayorg...
> in news:3c988556@news.povray.org Gleb wrote:
>
> Try the piece of code below. It produces black {} inside the macro. It
--- cut ---
Definitely a bug, thank you so much indeed.
Gleb
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christopher James Huff" <chr### [at] maccom <mailto:chr### [at] maccom>
<<mailto:chr### [at] maccom>>> wrote in message
<<news:chr### [at] netplexaussieorg>>...
> It seems that POV doesn't support nested multiline comments.
> Actually, it does. With this:
> /*
> Part 1
> /*
> Part 2
> */
> Part 3
> */
> The whole thing, from Part 1 to Part 3 is a comment.
>The syntax coloring in the editor might mess it up though.
That was a point! Thank you, I can see now. I've only tried to simulate the
editor scheme.
This is much better, and definitely more convenient. But in this case it
should be considered as a tiny bug
in POV editor?
Cheers!
Gleb
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c98c0b4$1@news.povray.org>, "Gleb" <gk1### [at] sotonacuk>
wrote:
> This is much better, and definitely more convenient. But in this case it
> should be considered as a tiny bug in POV editor?
As far as I recall, the Windows editor uses a version of CodeMax that
was donated. CodeMax was designed for C/C++ code, so it uses that for
coloring, and if I remember correctly the POV-Team can't legally modify
it.
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:chr### [at] netplexaussieorg Christopher
James Huff wrote:
> CodeMax was designed for C/C++ code, so it uses that for
> coloring, and if I remember correctly the POV-Team can't legally modify
> it.
>
It has gone open source a few years ago, but now it's 'dead'.
http://groups.yahoo.com/group/codemax/
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
