Update of bug #68022 (group groff):
Status: Need Info => Confirmed
Planned Release: None => 1.24.0
_______________________________________________________
Follow-up Comment #7:
[comment #5 comment #5:]
>> Is there no alternative, plain-text representation format for these streams
>> specified? Not Base64 or something like that?
>
> There plenty of strean filters which can be applied:-
>
> ASCIIHexDecode
> ASCII85Decode
> LZWDecode
> FlateDecode
> RunLengthDecode
> CCITTFaxDecode
> JBIG2Decode
> DCTDecode
>
> But Flate is generally used. To actually see the contents of the stream you
> want no filter, but given font .pfb data is binary even with no filter the
> data is meaningless to read, so dropping it saves a lot of pgup/pgdowns when
> examining the pdf.
It's sometimes helpful to me to be able to observe a change in a binary data
stream by seeing how the values of the bytes change, whether by hex dump,
Base64 encoding, UU encoding, or what have you.
Not that I can decode such streams by eye, but it can tell me how much impact
a change had on those streams--often we expect "none at all".
That of course won't work if the streams thus encoded are strongly
history-dependent, which commonly happens when compression is applied. Once
one byte changes, all the rest in the stream generally do too.
Are the streams in PDF designed that way?
> I'm happy with -f/--format-options, and I know your documentation skills are
> better than mine, so please do patch.
Okay, I'll work on it.
> I've attached the png via the web page (have you found a way of attaching a
> file via the email interface).
I have not. :(
[comment #6 comment #6:]
> Updating fields to reflect discussion (which I hope I'm understanding
> correctly). Even though renaming the option technically requires a code
> change, it's not changing any code _logic_, so I feel it still qualifies as a
> documentation change rather than a feature one.
Thanks, Dave. I'd split the hair differently. It's a code change because it
changes a file that is compiled/interpreted, and things like accidental
semicolon omission can occur and wreck stuff.
But, there's no code freeze on Perl code currently in force on _groff_'s
master branch. Just C/C++. Which I've found four causes to violate. :-/
But either way, resolving *this* ticket requires violating no rules,
self-imposed or otherwise.
Also, FYI, I've made bug #65099 depend on this one.
Updating Status and Planned Release.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68022>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
