ASCII-85 Encoding per PS 3rd ED Spec

Thread View: adobe.postscript.programming

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by Outtascope Wed, 04 Oct 2006 15:47

#267

Author: Outtascope
Date: Wed, 04 Oct 2006 15:47

10 lines
2175 bytes

Is there an error in the Postscript Language Reference regarding ASCII-85 Encoding or am I just fundamentally messed up?

According to the spec as I read it, if your input data ends with n bytes, where n is less than 4, you pad the data with 4 - n zeros to create the base 256 4-tupple. You then encode as normal (convert to base 85, add 33 to each byte to make it printable), but only output the first n + 1 bytes.

This presumes that you could encode an 8 bit byte with only two base 85 digits. While this is true, it does not hold if you encode it "normally".

For instance, consider an input file consisting of a single digit: "."
The ascii value for . (period) is 46. Our resulting 4-tupple of 46,0,0,0 gives us an integral value of 771751936. Coding this in base-85 gives us the sequence of 14,66,56,74,46 or /cYGO after applying the addition of '!' (ascii 33) to each digit to get it in the printable range. According to the spec this would be output simply as /c followed by ~> (n+1 digits plus EOD marker). Subsequent decoding of this, however, gives us a value of 45. You could encode 46 using two digits as /d, but no where in the spec can I see reference to doing this. You could also handle this in the decoder, recognizing /c as 46 rather than the calculated 45. Since it isn't clearly specified, you have a 50/50 chance or either fixing the error, or compounding it.

Is my understanding correct or can anyone tell me the error that I am making? Thanks.

Re: ASCII-85 Encoding per PS 3rd ED Spec

#268

Author: Alex_Cherepanov
Date: Sun, 08 Oct 2006 02:13

39 lines
2258 bytes

Outtascope@adobeforums.com wrote:

> For instance, consider an input file consisting of a single digit: "."
> The ascii value for . (period) is 46. Our resulting 4-tupple of 46,0,0,0
 > According to the spec this would be output simply as /c followed by ~>
This is correct.

> Subsequent decoding of this, however, gives us a value of 45. 
The spec declares that the information is sufficient for deciding
but leaves development of the decoding algorithm to the exercise
of the reader. For instance, Ghostscript uses the following
procedure to decode the remaining bytes.

int a85d_finish(int ccount, ulong word, stream_cursor_write * pw)
{  /* Assume there is enough room in the output buffer! */
    byte *q = pw->ptr;
    int status = EOFC;
    switch (ccount) {
         case 0:
             break;
         case 1:         /* syntax error */
             status = ERRC;
             break;
         case 2:         /* 1 odd byte */
             word = word * (85L * 85 * 85) + 85L * 85 * 85 - 1L;
             goto o1;
         case 3:         /* 2 odd bytes */
             word = word * (85L * 85) + 85L * 85L - 1L;
             goto o2;
         case 4:         /* 3 odd bytes */
             word = word * 85L + 84L;
             q[3] = (byte) (word >> 8);
o2:         q[2] = (byte) (word >> 16);
o1:         q[1] = (byte) (word >> 24);
             q += ccount - 1;
             pw->ptr = q;
     }
     return status;
}

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads