Re: Copy & Paste

Greetings "Tim Doty" < drakki%40rollanet.org">drakkirollanet.org>
On 07/04/2007 at 14:34 you wrote concerning
Re: [PageStreamSupport] Copy & Paste

Hi Tim,

<<snip>>

TD>&gt; Although clumsy to describe, the 'screwups' related
TD>> above result from rather simple operations. In more
TD&gt;> complicated paragraphs, the results can be really
TD>> confusing. If I use the Edit Palette to "set things
TD>> right"; and then look at the text formatting codes, then
TD&gt;> it makes sense -- sometimes. Additionally, on doing so,
TD&gt;> I observe the 'missing' text descriptors appear roughly
TD>> where I expect them. But having to resort to the
TD&gt;> examination of the text formatting codes is ridiculous.

TD&gt;> It has reached the point that in a doc of even
TD&gt;> 'moderate'
TD>&gt; complexity or a 'longish' document, I avoid using the
TD&gt;> PASTE
TD>> operation for fear of weird results propogating
TD>&gt; through
TD>> large areas of text. From my point of view, COPY and
TD&gt;> PASTE
TD>> in PageStream is simply defective. Either that or
TD>;> after all
TD&gt;> these bloody years I still do not know how to perform
TD>> these
TD>> operations with any competence.

TD&gt; There are some difficulties with using copy and paste of
TD>; text in PgS though some of the problems you describe
TD> have, I think, been alleviated in more recent versions.
TD> Out of long habit I suppose I never use copy and paste
TD> of text in PgS, instead I do that sort of editing in an
TD>; editor (and is a major reason why I ported the
TD&gt; SendToEditor script to Python).

More recent versions!?!?!? Do you allude to Windows and Linux versions?

Yes, I agree that 'normally' one should do as much text editing within some
editor, like PageLiner in an Amiga setup, but in 'finishing' a document that is
not a reasonable solution. If, for example, I want to 'copy' an earlier
paragraph consisting of several hundred characters strokes, retyping same, or
from PageLiner saving the text to another file and then importing that into the
PageStream document, is simply not reasonable. Even copying from another
PageStream document -- with the added complications that that implies -- should
be possible and I have done so on many occasions. But such practice is
unreliable as I really do not understand what I am copying.

<<;snip>&gt;
TD> Why does this happen? Having looked at and fixed text
TD&gt; suffering from these problems in my opinion it is caused
TD> by PgS trying to maintain formatting. If you get right
TD> down to it this can be a tricky thing because PgS
TD&gt; doesn't know your /intent/. So it tries to preserve the
TD&gt; formatting of the copied text by grabbing context.

Of course, PageStream cannot know a user's intent, but, for example, a different
type of copy could be made available; e.g., a copy operation wherein the
formatting codes are not copied. On occasion, this would be useful. Another
useful variation might be:

%% One highlights a paragraph or several paragraphs.

%% One requests that PageStream -- not PageLiner -- show the formatting codes
that apply to the highlighted paragraphs, and they are displayed.

%% Once the highlight is broken, the area of text reverts to its former
'formatted' version.

I'm not sure if the above is a reasonable request, just sort of wondering about
this matter. Of course, one can do that now within PageLiner, but oscillating
back and forth from PageLiner can be counter-productive.

TD> There are times when this is the behavior you would
TD> want, such as copying a complete body of formatted text
TD&gt; and pasting it to a new location. However, if you copy
TD&gt; text internal to a paragraph and paste it internal to a
TD> new paragraph you probably want it to take on the
TD&gt; formatting of the new paragraph -- except for applied
TD> formatting.

In the context above, the ability to copy WITHOUT the formatting codes would be
useful.

TD&gt; If everyone used styles and in a uniform fashion then
TD&gt; PgS /could/ alter behavior to preserve styles in the one
TD&gt; case and not the other. But trying to second guess the
TD&gt; user ends up in complaints (see MS Word for reference).
TD> I don't fault PgS for what I see as the basic approach
TD> of trying to preserve the formatting of text.

I don't follow what you claim PageStream is trying to do here.

Clearly it is impossible to require that users apply styles in some "uniform
fashion." Cannot imagine Amigans buying that idea.

<<snip>;>
TD&gt; I assume you are referring to things like
TD&gt; PHeader1:PParagraph:PHeader1:PParagraph: repeated ad
TD>; naseum?

Not really, I can understand how the above can happen because of my vascillating
directions to PageStream. Sometimes PageStream will repeat the parameters for
'characters' which I'm not able to understand. I gave an example in the original
message.

TD&gt; That is a long standing flaw and one that I argue can be
TD>; programmatically solved. It is a little problematic
TD> though.

If Deron had nothing else to do, he probably could program a "Clean Up"
operation, but I wonder how difficult that would be???

<<snip>>
TD> In PgS a style need not, and rarely does, declare all
TD&gt; possible formatting attributes. Those that are not
TD&gt; defined are picked up from the previous style. If the
TD&gt; previous style does not set the attribute then they are
TD&gt; picked up from the previous style ... until you get to
TD>; the beginning of the article in which case they are set
TD&gt; by the default attributes.

But if you do not specify an attribute, then the relevant one back in <No Style>
may be used -- I think. That can lead to surprises! I tend to specify
everything under the sun when defining a new style, even if it means repeating
parameter values.

Also, one's *first* style must be based on something and the obvious something
is <No Style>.

TD>; There is one additional wrinkle: as PgS scans back to
TD>; find the setting of a format attribute it will stop at
TD>; an applied format. And this causes mixing of applied
TD> formatting with styles as an almost inevitable result
TD> due to the scarcity of styles covering all formatting
TD> attributes.

I don't get the above. By "applied formatting" I assume you mean something like
changing something like '1st' within some paragraph style to '1' followed by
'st' set in superscript format. So, I see the 'mixing' of styles and "applied
formats" as natural and don't quite follow what you are getting at.

TD> So having PHeader1:PParagraph: is perfectly valid,
TD> despite the fact that I would never use it. There would
TD> always be pathological cases, but repeating patterns,
TD> e.g., PS1:PS2:PS1:PS2:PS1:PS2:PS1:PS2:PS1:PS2:
TD&gt; could be reduced to PS1:PS2: and PgS does not
TD&gt; currently do this.

Yes, that would be some sort of "Clean Up" operation that I alluded to above.

Although 'PHeader1:PParagraph:' is indeed valid, I fail to see its
usefullness. In

PHeader1:PParagraph:«some text»

only the style 'Paragraph' would be applied to the textual material «some text»
or am I wrong again?

TD>>; Oh, by the way, I still have not figured out the
TD&gt;> difference between 'Paste' and "Paste as is". I hope
TD&gt;> you have.

TD&gt; Sorry to say I had even forgotten there was a "Paste as
TD>; is" because I never really use copy/paste in PgS.
TD&gt; Looking.... okay, you've got me. Where is "Paste as is"?

Go to

File -> Preferences... -> Toolbar

and then scan down the 'Commands' column. Eventually, you will come to a "Paste
As Is" icon. It is the same icon as the one for 'Paste' except that the usual
icon is followed by the character 'x'. Long time ago, I put it into my Toolbar,
but have rarely used it.

Cheers Don (Green Dragon)
--

Messages in this topic (0) Reply (via web post) | Start a new topic

.

Don:

> ...%% One highlights a paragraph or several paragraphs.
>
> %% One requests that PageStream -- not PageLiner -- show the formatting codes
&gt; that apply to the highlighted paragraphs, and they are displayed.
>

Actually, I have long advocated the WordPerfect method of showing a line
of text including the codes in a window at the bottom of the screen. The
text in the window follows the location of your cursor and you can edit
directly in the window as well. Hence, you can edit the text codes
without the extra export/import operation. It's simpler and actually
educational. Way back when I had WordPerfect, I learned a lot about how
the application actually did its thing because of that window.

I vaguely remember someone saying that this suggestion is either under
consideration or on the To Do list. I think it may have been Dan at
Grasshopper. On the other hand, everything I've written in this
paragraph could be a mirage.

Personally, I haven't used Send To Editor in ages. I've usually found
that I can fix the problem one way or another directly in PageStream in
about the same time it would take me using that method. Plus I know for
sure I've fixed it. I've had experiences where I thought I had fixed it
in the ASCII editor only to have PageStream change it back. At least
with the text window method, you get immediate feedback.

I should say that I used Send To Editor quite a bit in my Amiga days and
was fairly conversant in what the text codes were and where they
belonged. I'm not anymore, and that makes it easy for me to miss
something or make mistakes in handling them. I also can't resist
removing redundant codes, and that wastes a lot of time. I can't get it
into of my head that they don't matter. They confuse me, but not PageStream.

For importing from Word, I usually set up my paragraph styles in
PageStream and copy the ASCII text at the appropriate points or just
have the predominant paragraph style active when I paste and handle
exceptions after the paste. But I have imported RTF directly on occasion.

HB

Messages in this topic (0) Reply (via web post) | Start a new topic

.

>> ... I have long advocated the WordPerfect method of showing a line of
>>; text including the codes in a window at the bottom of the screen. The
>>; text in the window follows the location of your cursor and you can edit
>>; directly in the window as well. Hence, you can edit the text codes
>>; without the extra export/import operation. It's simpler and actually
>>; educational.
>&gt;
>&gt; I vaguely remember someone saying that this suggestion is either under
>>; consideration or on the To Do list. I think it may have been Dan at
>>; Grasshopper.
>
> If adding WordPerfect-like display of codes to PageStream is under
> consideration, let me add my voice in recommendation. I've used
> WordPerfect since version 4.something, including use of styles. The
> ability to see the codes (and hide them when not needed) is so much
> better than guessing why text appears a certain way. And you can correct
> erroneous or extraneous codes, resulting in a more stable document.
>
&gt; Relevant to Copy & Paste: When you can see the codes, you can avoid
> accidentally including ones from adjacent text when highlighting text to
> copy.

I'll third that suggestion (WP-like display of codes in a window)!

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Saklad mailto: jimdoc%40iname.com">jimdociname.com

Messages in this topic (0) Reply (via web post) | Start a new topic

.

Henry G Belot wrote:

>>...When you can see the codes, you can avoid
>>;accidentally including ones from adjacent text when highlighting text to
>>;copy.
&gt;
> Yes, a really important advantage that I'd forgotten about. I think a
> lot of the problems we experience with cut- or copy-and-paste between
> applications come from exactly that. When one of a paired set is
> missing, it's fairly obvious. But when an errant code stands alone, it
> can be hell to find and correct.

Yet another major use for WP's 'reveal codes': dealing with the jumble
of such codes that OCR can generate, unless one turns off formatting
altogether. Having such a feature added to PGS would be on my wishlist, too.
--
Mike Wilson

Messages in this topic (0) Reply (via web post) | Start a new topic

.

Michael:

> ...Yet another major use for WP's 'reveal codes': dealing with the jumble
> of such codes that OCR can generate,

Hmm. This thread is making me think that when I replace this computer, I
should pick up WordPerfect. Historically speaking, my favorite word
processors have been Decmate, WordStar, and last Word. However I adopted
Word at the tail end of the MSDOS era primarily because I needed its
ability to generate parallel columns for the industrial scriptwriting
format I used in my work. I forget what I had against WordPerfect at the
time.

(Decmate could do parallel columns too, but it was a standalone word
processor running on DEC's PDP 11, so I had to be at work to use it. At
the time I moved to CP/M, Decmate didn't have WYSIWYG, but it got the
job done with the help of a few macros. Again at that time, DEC was
geared toward daisy wheel printing almost exclusively. When you did
parallel columns it printed the first column, backed the page up, then
printed the next column. Decmate had 96KB of memory. WordStar on my CP/M
had 64 but needed only 32. For a time I ran WordStar on my Amiga. I had
a bridgeboard which gave me MSDOS and a CP/M card which ran off of that.
So it was a computer within a computer within a computer. And it worked
just fine. I still have all that hardware in the attic.)

HB

Messages in this topic (0) Reply (via web post) | Start a new topic

.