POV-Ray : Newsgroups : povray.documentation.inbuilt : 3.7xx: max_extent (re: image resolution) is missing something? Server Time
25 Sep 2021 04:33:33 EDT (-0400)
  3.7xx: max_extent (re: image resolution) is missing something? (Message 11 to 12 of 12)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: clipka
Subject: Re: 3.7xx: max_extent (re: image resolution) is missing something?
Date: 9 Jun 2017 16:00:47
Message: <593afe6f$1@news.povray.org>
Am 09.06.2017 um 19:56 schrieb Kenneth:

> (A little side note: I can actually open the help file--in its entirety-- in
> Windoze Wordpad. The contents are meaningless of course, mostly symbols. But It
> doesn't open likewise in POV-Ray-- just one little 'word.' I thought POV was
> robust enough to open and display just about any 'programming language.' But
> then again, I'm somewhat naive about 'compiled' languages ('somewhat'?? That's
> an understatement!!) ;-)

The help file is a binary file.

Most "compiled" stuff is binary files.

A binary file may contain arbitrary sequences of arbitrary bytes, from 0
to 255 (hexadecimal 00 to FF).

Most notably, a binary file may contain byte value 0 (hexadecimal 00)
anywhere in the file.

The vast majority of programming languages is based on plain ASCII text

A canonical ASCII text file may contain only bytes that represent
_printable_ ASCII characters (32 to 126 = hexadecimal 20 to 7E), as well
as a few select control characters (horizontal tabulator, line feed,
carriage return, end of file = 9, 10, 13, 26 = hexadecimal 09, 0A, 0D, 1A).

Most notably, an ASCII text file must _never_ contain byte value 0
(hexadecimal 00) _anywhere_ in the file.

When a program handles text, it needs to keep track of where the text
ends. One obvious way to do this is to store the length in a separate
numerical data field, but this has the drawback of potentially wasting a
lot of memory if you're working with lots of small yet occasionally
large pieces of text: Unless you want to restrict yourself to at most
255 characters per piece of text, you need to set aside at least 2 extra
bytes per piece of text for that length data field; and if your text
pieces may potentially exceed 65535 characters, you'll need 4 extra
bytes for the length data field.

A more compact scheme is to not store the length of the text, but rather
mark its end with a special pseudo-character; this only requires 1 extra
byte per piece of text (presuming the text uses byte encoding such as
ASCII, or byte-based variable-length encoding such as UTF8). Commonly,
the byte value hex 00 is used as this end-of-string marker, in which
case this scheme is referred to as "null-terminated strings".

Virtually all text editors can cope with files containing arbitrary
characters from the range 1 to 255 (hexadecimal 01 to FF), at least to
some degree; but text editors that happen to use null-terminated strings
to store the lines of text may screw up on any files containing the byte
value hex 00.

The text editor module in POV-Ray for Windows presumably suffers from
this null-terminated-string ailment, while the Windows Wordpad
apparently does not. Whether it is because Wordpad does not use
null-terminated strings, or because it immediately replaces any hex 00
byte value with a placeholder upon loading, I can't tell.

Post a reply to this message

From: Jim Holsenback
Subject: Re: 3.7xx: max_extent (re: image resolution) is missing something?
Date: 10 Jun 2017 08:42:04
Message: <593be91c$1@news.povray.org>
On 6/9/2017 12:19 PM, clipka wrote:
> Am 09.06.2017 um 14:41 schrieb Jim Holsenback:
>> On 6/9/2017 8:15 AM, Jim Holsenback wrote:
>>> ... they didn't make it into the docs most likely due to a foo
>>> somewhere with regex pattern matching in WikiDocGen. I'll have a look
>> i take it back ... a quick look on the wiki and i think it's the markup
>> concerning < and > that appear (and is missing in one place ... the box
>> declaration) where > and < should have been used in the predefined
>> text blocks that encloses the examples. this weekend i'll make some
>> edits and test my theory.
> I concur.


> the help file viewer apparently misinterprets it as a (malformed) HTML
> tag. The text is actually in the help file, but it's not displayed.

same deal with the nix and mac versions ... i turned on debugging and 
ran WikiDocGen before making the edits on the wiki and discovered a few 
things that i've had to mark as fix me. basically i need to test <pre> 
blocks rather than JUST keep reading until i find </pre> ... btw: i 
looked at the history on the wiki and i guess a mea culpa is in order 
because it looks like i'm the one who busted that passage. check your 
email ... i've posted an update to include in the next release

Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.