At 3:29 pm -0500 19/03/01, Ronald J Kimball wrote:
> > So far as I can see it is a bug in LowMem.
>
>Actually, according to the explanation John Baxter posted, each section
>must use an even number of bytes. This means there will be an extra
>padding byte added to a section whose length is odd.
At 11:44 pm +0100 19/03/01, Bart Lateur wrote:
>Damn, you guys beat me to it. Ok, here's how I would have done it. Note
>that the functionality is the same.
Oh, but it was worth waiting for: it is so elegant:
> (my $data, $_) = unpack "x8a${len}x@{[$len & 1]}a*", $_;
The "even/uneven"
At 12:07 +0100 3/19/01, Bart Lateur wrote:
>* The length of the data, is that including this 8 byte header (as with
>JPEG), or just the appended data?
If memory serves (and I think it does, because the IM wording seems to
agree), it is the length of the data, so that the offset from type n to
typ
At 15:21 +0100 3/19/01, Bart Lateur wrote:
>>This issue of processing StyledText data is a long story for me. Years
>>ago, I first was interested in it when I downloaded and studied a Frontier
>>suite named "StyledText", written by John (Baxter).
>
>John Baxter? Could this possibly be the same Jo
At 12:35 + 3/19/01, Alan Fry wrote:
>As you said in an earlier post this _presumes_ that the number
>following each 'four character group' will be a 'long'. In the case
>of the MSWD extract above 'DSIG' is an MS key, rather than a MacOS
>key, so one would be reliant on BG doing the expected th
>On Mon, 19 Mar 2001 22:21:24 +0900, Nobumi Iyanaga wrote:
>
> >This issue of processing StyledText data is a long story for me. Years
> >ago, I first was interested in it when I downloaded and studied a Frontier
> >suite named "StyledText", written by John (Baxter).
>
>John Baxter? Could this po
On Mon, 19 Mar 2001 15:29:14 -0500, Ronald J Kimball wrote:
>I think adding a line to your code should fix this bug:
>
>#!perl
>use Mac::LowMem;
>
>$lmh = LMGetScrapHandle;
>$str = $lmh->get;
>
># diagnostics...
> #print "$str\n\n";
> #@l = split(//, $str);
> #foreach (@l) {print ord(
On Mon, Mar 19, 2001 at 06:49:19PM +, Alan Fry wrote:
> At 9:41 am -0500 19/03/01, Ronald J Kimball wrote:
>
> >I did provide sample code, in an earlier response to Alan. The correct and
> >robust approach is to start at the beginning of the string and process the
> >sections in order.
>
>
At 9:41 am -0500 19/03/01, Ronald J Kimball wrote:
>I did provide sample code, in an earlier response to Alan. The correct and
>robust approach is to start at the beginning of the string and process the
>sections in order.
(I had some difficulty getting that to work and revised it using
'subst
On Mon, Mar 19, 2001 at 09:13:04AM +0100, Detlef Lindenthal wrote:
>
> Ronald J Kimball wrote:
>
> > Still, I don't know why it would be preferable to
> > write a solution with these obscure limitations (which will be difficult to
> > debug if they're ever hit) when there's another approach whic
At 22:21 +0900 2001-03-19, Nobumi Iyanaga wrote:
>On the other hand, if there is a way to pass "styl" and "TEXT" data to
>MacPerl as @ARGV data, we would be able to write an AppleScript script
>looking like this:
>
>set stxt to ""
>tell application "Style"
> set stxt to selection of front do
On Mon, 19 Mar 2001 22:21:24 +0900, Nobumi Iyanaga wrote:
>This issue of processing StyledText data is a long story for me. Years
>ago, I first was interested in it when I downloaded and studied a Frontier
>suite named "StyledText", written by John (Baxter).
John Baxter? Could this possibly
Hello Alan, Detlef, Bart, John, Ronald and others,
Thank you very much for your interest in my problem.
This issue of processing StyledText data is a long story for me. Years
ago, I first was interested in it when I downloaded and studied a Frontier
suite named "StyledText", written by John (
At 3:41 pm -0500 18/03/01, Ronald J Kimball wrote:
> > With the greatest respect I think you have both misunderstood what I
>> was driving at.
>
>I think we're all misunderstanding each other. :/
It's my fault -- my capacity for being unclear is as great as my
capacity for getting hold of the
At 9:13 am +0100 19/03/01, Detlef Lindenthal wrote:
>Ronald J Kimball wrote:
>
>> Still, I don't know why it would be preferable to
>> write a solution with these obscure limitations (which will be difficult to
>> debug if they're ever hit) when there's another approach which is correct
> > a
Ronald J Kimball wrote:
> Still, I don't know why it would be preferable to
> write a solution with these obscure limitations (which will be difficult to
> debug if they're ever hit) when there's another approach which is correct
> and robust.
>
> Ronald
>From my point of view: Because so far n
On Mon, Mar 19, 2001 at 01:09:12AM +0100, Detlef Lindenthal wrote:
> Hi Alan,
>
> you are right in that you look for precision/safety.
> The safety leak does not seem to be that big; what
> I found: Only if you have the (very rare) string "styl\0"
> within your text your programme will fuddle (or
Hi Alan,
you are right in that you look for precision/safety.
The safety leak does not seem to be that big; what
I found: Only if you have the (very rare) string "styl\0"
within your text your programme will fuddle (or
did I miss something?)
You could ask in the beginning of your script:
"styl\0"
At 12:45 -0800 3/18/01, John W Baxter wrote:
>4 bytes: type code (TEXT, PICT, styl, etc etc)
>4 bytes: length of the data (must be even)
>n bytes: the data
>Repeated until one runs out of stuff.
I put "(must be even)" in the wrong place...IM attaches it to "n bytes".
So the length can be odd
At 20:17 +0100 3/18/01, Bart Lateur wrote:
>I think that that "mush" itself is stored in some kind of tree. The key
>to traversing this tree should be some length words/longs, indicating
>how long the individual parts are. I expect it to be not to different
>from how JPEG and/or TIFF files are sto
On Sun, Mar 18, 2001 at 04:04:13PM +, Alan Fry wrote:
> At 9:09 am -0500 17/03/01, Ronald J Kimball wrote:
> >I don't think Bart has misunderstood the problem at all.
>
> With the greatest respect I think you have both misunderstood what I
> was driving at.
I think we're all misunderstandin
On Sun, 18 Mar 2001 16:04:13 +, Alan Fry wrote:
>>I don't think Bart has misunderstood the problem at all.
>
>With the greatest respect I think you have both misunderstood what I
>was driving at.
>
>>Take the first four characters, which indicate the type.
>
>That IS the problem. Those four
At 9:09 am -0500 17/03/01, Ronald J Kimball wrote:
>I don't think Bart has misunderstood the problem at all.
With the greatest respect I think you have both misunderstood what I
was driving at.
>Take the first four characters, which indicate the type.
That IS the problem. Those four merry litt
On Sat, Mar 17, 2001 at 02:02:55PM +, Alan Fry wrote:
> At 12:57:50 +0100, Sat, 17 Mar 2001 Bart Lateur wrote:
>
> >On Sat, 17 Mar 2001 11:17:10 +, Alan Fry wrote:
> > >So we really need to find a better way of isolating 'TEXT', 'styl'
> >>(and others like 'PICT' for example) from the st
At 12:57:50 +0100, Sat, 17 Mar 2001 Bart Lateur wrote:
>On Sat, 17 Mar 2001 11:17:10 +, Alan Fry wrote:
> >So we really need to find a better way of isolating 'TEXT', 'styl'
>>(and others like 'PICT' for example) from the string returned by
>>LMGetScrapHandle. It must be set out somewhere in
On Sat, 17 Mar 2001 11:17:10 +, Alan Fry wrote:
>So we really need to find a better way of isolating 'TEXT', 'styl'
>(and others like 'PICT' for example) from the string returned by
>LMGetScrapHandle. It must be set out somewhere in IM: the question is
>where.
I'm too tired and too busy r
At 1:51 am +0100 17/03/01, Detlef Lindenthal wrote:
>Your and Nobumis programm gave me the thought of trying a
>little step ahead:
Thank you for your kind comments. However a word of warning: the
'regex' looking for /TEXT/ and /styl/ are not really secure. Both
strings can (and do) occur in pl
Alan Fry wrote:
> I hope this is helpful,
>
> Alan Fry
Yes, Alan, I T I S helpful! ("You are my very personal hero"
or s.th. like that my son would have said in such a case :-) )
Your and Nobumis programm gave me the thought of trying a
little step ahead:
With your extracting of style pl
At 3:02 pm +0900 16/03/01, Nobumi Iyanaga wrote:
>If I could write all this in MacJPerl, I would be very glad. But it
>seems that the data that I get from (the code by Alan Fry):
>
> use Mac::LowMem;
> my $lmh = LMGetScrapHandle;
> my $str = $lmh->get;
>
>seems not exactly
>On Wed, 14 Mar 2001 21:20:46 +0900, Nobumi Iyanaga wrote:
>
> >I have a MacPerl script which gets the 'styl' resource from a file (of
> >SimpleText type), and analyses it (it is a friend of mine who wrote this
> >script)
>
>Some friends you have. I would very much like to see that script.
>
>As f
At 9:30 am +0100 15/03/01, Bart Lateur wrote:
>As for your problem: Perl has good access to the toolbox, so I think it
>must be feasable to make MacPerl get the data directly from the
>clipboard, without aid of Applescript? Anybody?
You may be able to get what you want from LMGetScrapHandle:
On Wed, 14 Mar 2001 21:20:46 +0900, Nobumi Iyanaga wrote:
>I have a MacPerl script which gets the 'styl' resource from a file (of
>SimpleText type), and analyses it (it is a friend of mine who wrote this
>script)
Some friends you have. I would very much like to see that script.
As for your pr
Two remarks:
1. It seems to me that the following scriptlet is not a
proper Apple Script:
"set stxt to the clipboard as styled text
set stxtRecord to another data of stxt but type is record
set txt to <> of stxtRecord
set stl to <> of stxtRecord
stl"
My proposal: Write this
Hello,
I want to read and process StyledText data that I will get from the
clipboard in MacPerl.
I know that StyledText data can be splitted in to a record of "ktxt" data
and "ksty" data. The following AppleScript script:
set stxt to the clipboard as styled text
set stxtRecord to another dat
34 matches
Mail list logo
