In article <3e1345e3$1@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> Not that it changes anything about your valid argument, but (IEEE 754)
> single precision floating-point numbers still take only four bytes, not
> eight.

Thanks for the correction, I knew I should have double-checked it...

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

> And it also produces so much better PDF output... ;-)

	Not really: see for instance page 19 of the current PDF docs,
there are not PDF hyperlinks and no thumbnails in the file.
	Use PDFLaTex  ;op

	- NC

Post a reply to this message

On Tue, 31 Dec 2002 21:43:19 -0500, Christopher James Huff
<cja### [at] earthlinknet> wrote:
> I've been thinking about this for a while...one thing I've always wanted 
> was a way to create different "buffers" for filter input and output. 
> That way, you could run two different filters on the raw image, and 
> combine them with another filter, or output multiple processed versions 
> of the same image.

Yes, that's exactly I have in mind. I also want to made is as pre-process for
image-maps. Not talking about connecting it with function VM.

ABX

Post a reply to this message

On Wed, 01 Jan 2003 21:01:45 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> > IE 5 Windows
> > Mozilla 1 Windows
> > Konqueror 3.0.1 Linux
>
> Indeed, a good selection of browsers for Mac users ;-)

Well, we have also txt version (it is in included dos archive) so there should
be no problem with the browser in that case ;-)

> Besides, if DocBook and XML are so good, why does the official documentation
> based on a proprietary system of extended HTML work so much better and on
> all browsers?  ;-) ;-) ;-)

That's not the problem of the DocBook idea but problem of rendering process. I
had not much time to customize all features available in free XSL stylesheets
and templates at http://docbook.sourceforge.net/projects/xsl/index.html. Also
I choosed xhtml as target for output for documentation. It is possible to use
'traditional' html. Please, verify:

html chunked: http://megapov.inetart.net/manual/html/index.html
html long: http://megapov.inetart.net/manual/html/megapov01.html

xhtml chunked: http://megapov.inetart.net/manual/index.html
xhtml long: http://megapov.inetart.net/manual/megapov01.html

I have checked xhtml output in validators but noticed only report about missed
alt and unnecessary "xmlns" attribute. Now I rechecked this and it seems
during development there appeared some duplicated ids. I have to investigate
it more. I have already found some bugs in free XSL files and some were fixed
for our release.

ABX

Post a reply to this message

On Thu, 02 Jan 2003 00:09:05 +0100, Nicolas Calimet <pov### [at] freefr> wrote:
> > And it also produces so much better PDF output... ;-)
>
>	Not really: see for instance page 19 of the current PDF docs,
> there are not PDF hyperlinks and no thumbnails in the file.

page 19 counting from first or page 19 counting from numbered as "1" ? :-)

In case of some urls there was no <ulink> tag applied. So I have to know what
tag you mean exactly to verify a bug. Please be more specific to help us make
it better.

>	Use PDFLaTex  ;op

Note, we are multienvironment team: windows (development tested on 95, 98, NT
and probably more), linux, mac (various versions) and we need effective but
uniform development. XSLT processors are easier to operate than TeX
environment. I could not force to work any of PDF outputs using TeX. I have
already looked for help with some experienced persons and could not find any.
But DocBook sources are available, if you have some experience, free time and
can provide tutorial how to do it for all mentioned platforms, please help us.

Any help in making MegaPOV documentation better either in appearance and
content is welcome.

ABX

Post a reply to this message

In article <msp71v8a6018mhh2apioh9anqa6b7om4ov@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

> I choosed xhtml as target for output for documentation. It is possible to use
> 'traditional' html. Please, verify:

XHTML???  For what reason would any sane person use XHTML?  On the other
hand, if your goal is to break as many browsers as possible, using XHTML is
fine, of course.

> html chunked: http://megapov.inetart.net/manual/html/index.html

Well, seems to work fine everywhere.  Except that Netscape 4.78 still
doesn't render the preformatted elements correctly.  I really wonder what
you did to break this?!?

    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 <msp71v8a6018mhh2apioh9anqa6b7om4ov@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

> I have checked xhtml output in validators but noticed only report about missed

Don't tell me that is all the testing you did???

    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

> That would use huge amounts of memory, and I'm not sure how useful it
> would be. Using accumulation buffers would have big limitaitions, like
> only blurring things on objects seen directly.

Here is a simulated example (http://195.221.122.126/layers/layers.html) to see
what happens
i agree that
- it's probably useless for scene with lots of reflection/refraction
- it allows to tweak, and *fake* stuff (and this can sound like heresy to
ray-tracer integrists :)

M

Post a reply to this message

Mael wrote:
> 
> > That would use huge amounts of memory, and I'm not sure how useful it
> > would be. Using accumulation buffers would have big limitaitions, like
> > only blurring things on objects seen directly.
> 
> Here is a simulated example (http://195.221.122.126/layers/layers.html) to see
> what happens
> i agree that
> - it's probably useless for scene with lots of reflection/refraction

It is surely more difficult but with an object 'ID' output like Chris Huff
suggested you could generate a mask to post process only certain objects
(like blurring the floor reflection in your case) Of course this would
miss the indirect appearances of that object in other reflections etc. but
this is only relevant in some situations and can often be neglected.

> - it allows to tweak, and *fake* stuff (and this can sound like heresy to
> ray-tracer integrists :)

It is out of question that post processing effects are not as good as
doing things internally but they have great speed advantages.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 31 Dec. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Thu, 02 Jan 2003 11:17:30 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> XHTML???  For what reason would any sane person use XHTML?  On the other
> hand, if your goal is to break as many browsers as possible, using XHTML is
> fine, of course.

I don't remember exact reason why xhtml was used instead of html. I'm sure it
was becouse of some of several DocBook tutorials but can't recall url.
Everyone of us tested documentation versions on his native platform and it
seemed to work. I have also posted a link to you and you said nothing about
not readable pages, so I don't understand so much panic in your sentences :-)
It is a first release mostly concerned on building team, effective environment
and learning cooperation. It worked and we are happy about that. We can now
make it better. Would you like to provide some references according to "sane
persons vs. XHTML" ?

> > html chunked: http://megapov.inetart.net/manual/html/index.html
>
> Well, seems to work fine everywhere.

Then it will be changed probably in the future.

> Except that Netscape 4.78 still
> doesn't render the preformatted elements correctly.  I really wonder what
> you did to break this?!?

Nothing intentionally :-)

ABX

Post a reply to this message