 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, thank you all for your help,
I was sure that there are some ways to do it already.
But I've found this task interesting and I'd like to offer
you in your spare time to try this on-line version at
http://freelocus.com/pov2html.html
It uses pretty simple html <font> tags for now and
is limited up to 200 lines of code at once,
but I think it is still suitable for converting
sources for on-line tutorial, and (maybe) for docs too.
I hope that all keywords are included, but this is a question to test.
Regards,
Gleb
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gleb wrote:
> Well, thank you all for your help,
> I was sure that there are some ways to do it already.
> But I've found this task interesting and I'd like to offer
> you in your spare time to try this on-line version at
>
> http://freelocus.com/pov2html.html
>
> It uses pretty simple html <font> tags for now and
> is limited up to 200 lines of code at once,
> but I think it is still suitable for converting
> sources for on-line tutorial, and (maybe) for docs too.
Nice work! But there seems a problem with the newline characters. If I look
at the source everything appears on one line (the browser does not even
display everything).
Are the colours the same as in the windows version of POV-Ray?
I would prefer if the formating were done with css, so one could easily
customize the colours.
- Micha
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gleb wrote:
>
> Well, thank you all for your help,
> I was sure that there are some ways to do it already.
> But I've found this task interesting and I'd like to offer
> you in your spare time to try this on-line version at
>
> http://freelocus.com/pov2html.html
>
> It uses pretty simple html <font> tags for now and
> is limited up to 200 lines of code at once,
> but I think it is still suitable for converting
> sources for on-line tutorial, and (maybe) for docs too.
>
> I hope that all keywords are included, but this is a question to test.
Nice.
It would be great if you could supply the source code too, this would
allow to customize the settings easily, like having custom color schemes
or using CSS.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 13 Mar. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
All those people wanting interesting source codes..... he he he he :-)
--
Apache
http://geitenkaas.dns2go.com/experiments/
apa### [at] yahoo com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c9102a2@news.povray.org>, gk1### [at] sotonacuk says...
> I was sure that there are some ways to do it already.
> But I've found this task interesting and I'd like to offer
> you in your spare time to try this on-line version at
I found a serious bug: "*" is not highlighted red :-)
I've written one too in PHP (had to rename it to "ANOTHER Pov2Html
converter", since you were faster *g*)
http://mitglied.lycos.de/lpvader/pov2html/pov2html.php
It needs the Pov-Script to be already somewhere on the net, but also
allows a custom css-file.
Sorry for the popups, but on my homepage I don't have access to php, so I
had to get a free page at tripod to make it work online.
The source is in http://mitglied.lycos.de/lpvader/pov2html/p2h.zip
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Lutz-Peter Hooge" <lpv### [at] gmxde> wrote in message
news:MPG.16fbc0a42bdd79fe9896e6@news.povray.org...
> I found a serious bug: "*" is not highlighted red :-)
You found it! The only way to know that somebody does testing :)
> I've written one too in PHP (had to rename it to "ANOTHER Pov2Html
> http://mitglied.lycos.de/lpvader/pov2html/pov2html.php
> It needs the Pov-Script to be already somewhere on the net, but also
> allows a custom css-file.
I like it.
> Sorry for the popups,
Which ones? I haven't noticed any.
> The source is in http://mitglied.lycos.de/lpvader/pov2html/p2h.zip
Have you checked the list of keywords? An item "normal_indices" listed twice
in docs,
as was already mentioned in p.b-t. Nice sources, I don't have my ready yet.
Anyway imho the best will be to have "save as html" menu option in POV
editor.
Regards,
Gleb
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:3C911156.23B6B3EB@gmx.de...
> Nice.
Thank you.
> It would be great if you could supply the source code too, this would
> allow to customize the settings easily, like having custom color schemes
> or using CSS.
It is too raw yet. You can use Lutz-Peter's one however.
It is always nice to have alternatives to choose.
Gleb
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Micha Riser" <mri### [at] gmxnet> wrote in message
news:3c910f2d@news.povray.org...
> Nice work! But there seems a problem with the newline characters. If I
look
> at the source everything appears on one line (the browser does not even
> display everything).
Thanks! Nothing special, really. There are no newline characters there,
only <br> tags instead.
> Are the colours the same as in the windows version of POV-Ray?
I hope so.
> I would prefer if the formating were done with css, so one could easily
> customize the colours.
I agree. And not only colours, actually.
Gleb
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 14 Mar 2002 20:05:53 -0000, "Gleb" <gk1### [at] sotonacuk> wrote:
> But I've found this task interesting and I'd like to offer
> you in your spare time to try this on-line version at
>
> http://freelocus.com/pov2html.html
I think it hangs up with http://www.bmt.com.pl/Poligrodzianie/sigs.pov
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 15 Mar 2002 08:26:45 +0100, Lutz-Peter Hooge <lpv### [at] gmxde> wrote:
> I've written one too in PHP (had to rename it to "ANOTHER Pov2Html
> converter", since you were faster *g*)
>
> http://mitglied.lycos.de/lpvader/pov2html/pov2html.php
Pretty good. My testing file http://www.bmt.com.pl/Poligrodzianie/sigs.pov is
rather short but it appear with fatal error - execution time too long. Also
with some sample css ends of lines are broken.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"W?odzimierz ABX Skiba" <abx### [at] babilonorg <mailto:abx### [at] babilonorg>> wrote in
message <news:hjp39u87rcv46na1l4q7ctfth72qbf0plr@4ax.com>...
> I think it hangs up with <http://www.bmt.com.pl/Poligrodzianie/sigs.pov>
Thank you for testing.
Yes, the on-line version behaves a bit strange for me too, I'm not sure
about what the real limitations are.
But it processed these sigs for me in two steps ~ 100 lines + the rest.
Gleb
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <1qp39uklntb84ucah2fs5igj5r1ovvjkri@4ax.com>, abx### [at] babilonorg says...
> Pretty good. My testing file http://www.bmt.com.pl/Poligrodzianie/sigs.pov is
> rather short but it appear with fatal error - execution time too long.
Probably due to that sluggish lycos server. I called it with you file,
and is now sitting there for more than 9 minutes and has only displayed
the first 3 sigs until now...
Last night it was very responsive, bot now it takes ages to show
something at all :-(
> Also
> with some sample css ends of lines are broken.
Wich one? What do you mean with broken? Visible <br> Tags? or something
different?
(uhm, does't Windows and Unix use different markers for line-feeds?
Maybe that is the prob, since I only check for \n)
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c91debc@news.povray.org>, gk1### [at] sotonacuk says...
> > The source is in http://mitglied.lycos.de/lpvader/pov2html/p2h.zip
> Have you checked the list of keywords? An item "normal_indices" listed twice
> in docs,
Yep, of course than it's also twice in mine, since I only copy&pasted the
keywords list from the docs.
But it should't cause a problem, it's just one redundant check for every
token.
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <1qp39uklntb84ucah2fs5igj5r1ovvjkri@4ax.com>, abx### [at] babilonorg
says...
> rather short but it appear with fatal error - execution time too long.
Seems it was't the server alone. I did some profiling and found out that
for some mysterious reason array_pop() in PHP is extremely slow.
I replaced it with array_walk, and now the whole thing is about 8 times
faster.
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:3c9102a2@news.povray.org Gleb wrote:
> [...]
> http://freelocus.com/pov2html.html
> [...]
> I hope that all keywords are included, but this is a question to test.
It does not deal with nested multiline comments in the right way.
It has problems with a < preceded by a comma (no coloration)
It has sometimes problems with the {}
I tried to make a converter too this weekend, using python. It uses css,
but it has no file i/o yet, also replacing >,< etc. by proper html esc-
characters is not done yet.
Here's some of its results:
http://members.home.nl/seedseven/povcolor.html
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 15 Mar 2002 21:27:22 +0100, Lutz-Peter Hooge <lpv### [at] gmxde> wrote:
> Wich one?
after you changes it appears in with CSSs
> What do you mean with broken? Visible <br> Tags?
Yes. At begining sigs appear properly from "new of Warp" they seems broken.
Also all sigs are separated with empty line in original file.
Note that pair digit-token ("0translate" for example) isn't highlited
properly. It also isn't highlited in POV-gui but perhaps you can force this
:-)
> (uhm, does't Windows and Unix use different markers for line-feeds?
> Maybe that is the prob, since I only check for \n)
Meybe. For answer you should call 0 800 POV RAY ;-)
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <2ubb9uc70mfovpmpgdo5s29p84esaromg9@4ax.com>, abx### [at] babilonorg
says...
> Yes. At begining sigs appear properly from "new of Warp" they seems broken.
> Also all sigs are separated with empty line in original file.
I can't reproduce this. Maybe it is a bug in your browser (wich one)?
> Note that pair digit-token ("0translate" for example) isn't highlited
> properly. It also isn't highlited in POV-gui but perhaps you can force this
> :-)
I didn't even know the parser accepts such things...
Lutz-Peer
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 18 Mar 2002 14:52:50 +0100, Lutz-Peter Hooge <lpv### [at] gmxde> wrote:
> > Yes. At begining sigs appear properly from "new of Warp" they seems broken.
> > Also all sigs are separated with empty line in original file.
>
> I can't reproduce this. Maybe it is a bug in your browser (wich one)?
I'm using IE5. Take a look at urls:
result of your script: http://www.bmt.com.pl/Poligrodzianie/sigs_ie5.png
the same source in POV-Win editor:
http://www.bmt.com.pl/Poligrodzianie/sigs_pov.png
> > Note that pair digit-token ("0translate" for example) isn't highlited
> > properly. It also isn't highlited in POV-gui but perhaps you can force this
> > :-)
>
> I didn't even know the parser accepts such things...
It is unofficial feature for sig writers ;-)
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:Xns### [at] povrayorg ingo wrote:
> I tried to make a converter too this weekend, using python. It uses
> css, but it has no file i/o yet, also replacing >,< etc. by proper
> html esc- characters is not done yet.
>
It all works now:
http://members.home.nl/seedseven/povsdl2html.py
Fancy but probably useless things to add later, some more color-
dictionaries to choose from, optional line numbers, optional links from
identfiers and macros to the place where they where declared. A project
mode, feed it the top scene and it will do all associated include files
and generates appropriate links, maybe even for the standard includes. If
I feel like it, that is.
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4psb9ustotrcdg8qj6v0bksk8ceufosdmi@4ax.com>, abx### [at] babilonorg
says...
> I'm using IE5.
> Take a look at urls:
> result of your script: http://www.bmt.com.pl/Poligrodzianie/sigs_ie5.png
Thanks. It really seems to be a bug in IE, it seems that inside a <pre>-
block it interprets multiple <br> Tags as if there where only one.
> the same source in POV-Win editor:
> http://www.bmt.com.pl/Poligrodzianie/sigs_pov.png
Thats how it should look like, and it does in Netscape and Opera.
I'll find a fix for this (however the HTML and CSS code I used is legal
according to validator.w3.org).
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <MPG.17005ab86702672c9896ed@news.povray.org> , Lutz-Peter Hooge
<lpv### [at] gmxde> wrote:
> Thanks. It really seems to be a bug in IE, it seems that inside a <pre>-
> block it interprets multiple <br> Tags as if there where only one.
<br> tags don't belong inside a <pre> block. It is "pre" as in PREformatted.
So why would anyone add *formatting* tags while at the same time saying it is
preformatted? I would recommend to learn more about <pre> tags or use a
WYSIWYG editor :-)
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c964e9a@news.povray.org>, tho### [at] trfde says...
> <br> tags don't belong inside a <pre> block.
Maybe it doesn't seem to make a lot of sense, but it is legal syntax.
The reason I'm using a <pre> is because Netscape 4 had some problems when
I tried to replace the <pre> with a <div> or <p>, so I left it that way.
> It is "pre" as in PREformatted.
But that doesn't necessarily mean that additional formatting isn't
allowed.
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <MPG.17007534bd17b8a59896ee@news.povray.org> , Lutz-Peter Hooge
<lpv### [at] gmxde> wrote:
> Maybe it doesn't seem to make a lot of sense, but it is legal syntax.
Indeed, the DTD allows it. Probably it is for backward compatibility also I
don't know many browsers that support(ed) it...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 18 Mar 2002 20:42:18 +0100, Lutz-Peter Hooge <lpv### [at] gmxde> wrote:
> > I'm using IE5.
> > Take a look at urls:
> > result of your script: http://www.bmt.com.pl/Poligrodzianie/sigs_ie5.png
>
> Thanks. It really seems to be a bug in IE, it seems that inside a <pre>-
> block it interprets multiple <br> Tags as if there where only one.
I'm no good with english langauge details but I feel it can depend on
interpretation of specification. We can read at
http://www.w3.org/TR/html401/struct/text.html#edef-BR
"The BR element forcibly breaks (ends) the current line of text."
But what it should do when there is a break by <BR> already ?
When you write <B><B>word</B></B> is this word more bold ?
I suggest to use different handling of line breaks.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Lutz-Peter Hooge" <lpv### [at] gmxde> wrote in message
news:MPG.17005ab86702672c9896ed@news.povray.org...
>
> Thanks. It really seems to be a bug in IE, it seems that inside a <pre>-
> block it interprets multiple <br> Tags as if there where only one.
>
IIRC (and ignoring the oddity of having html tags within a <pre> block), that is
the correct behaviour. Multiple <br> or <p> tags should collapse. You need to
put a between each <br> if you want them maintained.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <soud9ucn05tt3h9qbsuiup1im475juefct@4ax.com>, abx### [at] babilonorg
says...
> "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.
This is how it works everywere else, and the specification doesn't say
in HTML it should behave different.
Also, for the P element the specification explicitly says that empty
blocks should be ignored. It does NOT say this for BR.
Furthermore I don't see a reason why an empty line should not be allowed
(multiple <BR> tags are the only way to achive it)
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.
I've now removed that silly <pre>, the problem I had with NN4 without it
is gone, probably fixed by some other changes I did before.
So I hope it will now work correctly everywere.
> When you write <B><B>word</B></B> is this word more bold ?
Thats a completely different problem (the BR's were not nested).
The correct question would have been:
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? ;-)
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <MPG.17017ad24611f7c09896ef@news.povray.org>, lpv### [at] gmxde
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
|
|
| |
| |
|
|
|
|
| |
