On May 17, 2004, at 11:51 AM, Vincent Lefevre wrote:
> I don't think that PS files can contain binary data (contrary to PDF).
> Binary is in fact encoded in hexadecimal (0-9,a-f).
I've some evidence that that isn't the case.
http://www.rfc-editor.org/rfc/rfc2046.txt
Page 17:
" (7) It is possible to include raw binary information inside
PostScript in various forms."
First this message:
http://www.imc.org/ietf-822/old-archive2/msg00424.html
Then, I did this:
acroread -toPostScript -level3 -binary < ImageMagick.pdf >
ImageMagick.ps
======== begin snip from ImageMagick.ps =======
/Width 573
/Height 437
/Filter /DCTDecode
/BitsPerComponent 8
/Decode [0 1 0 1 0 1]
/ColorSpace DefaultRGB
ID
????^@^NAdobe <binary data>
EI
Q
BT
======== end snip from ImageMagick.ps =======
Definitely non-ASCII data there.
> On 2004-05-17 11:44:29 -0500, Travis P wrote:
>
>> Even if it is completely text, do you really want PS files merged and
>> then resolve the conflicts yourself?
>
> Why not? Probably not with PS-generated files (anyway, marking files
> as binary doesn't solve conflicts magically),
I never even implied that it did. But if a merge occurs on an
unmerge-able file, recovering the original modified file could be very
difficult (maybe even impossible in some cases?). The user might want
an uncorrupted copy of the modified file to view his changes so as to
hand-incorporate them into the version that was checked in and which
conflicts which his own.
> but with hand-written
> PS files, yes, like with any other programming language.
You're right about hand-written text PS files. I think that
hand-written is probably quite the rare exception compared to generated
files. Too bad there isn't a recognized text/postscript mime-type for
the case you wish to deal with.
A related issue is: is this override-able? I suppose anything could
be set to application/octet-stream to force no merges.
If application/postscript change were made merge-able, I'd have to go
through my repos and change all my PS files which are currently marked
application/postscript to application/octet-stream because they are all
automatically generated files.
From that same RFC (http://www.rfc-editor.org/rfc/rfc2046.txt):
Page 4-5:
3. Overview Of The Initial Top-Level Media Types
The five discrete top-level media types are:
.....
(5) application -- some other kind of data, typically
either uninterpreted binary data or information to be
processed by an application. The subtype "octet-
stream" is to be used in the case of uninterpreted
binary data, in which case the simplest recommended
action is to offer to write the information into a file
for the user. The "PostScript" subtype is also defined
for the transport of PostScript material. Other
expected uses for "application" include spreadsheets,
data for mail-based scheduling systems, and languages
for "active" (computational) messaging, and word
processing formats that are not directly readable.
Note that security considerations may exist for some
types of application data, most notably
"application/PostScript" and any form of active
messaging. These issues are discussed later in this
document.
I would think that anything application/* (including application/xml)
should not be treated as mergeable text.
-Travis
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 17 19:43:59 2004