[duxhelp] Re: DBT 10.5 Beta 5
- From: "Peter Sullivan" <peter@xxxxxxxxxx>
- To: <duxhelp@xxxxxxxxxxxxx>
- Date: Wed, 11 Aug 2004 04:32:03 -0400
Christine,
I'm sorry -- it appears that you're describing a very different problem from
what I first thought.
The story about coded view and cursor placements remains the same: new
"problems" are likely due to what we regard as improvements, and so may
require script revisions.
But this problem is a different thing altogether. It does seem to make
things unworkable.
- Peter
-----Original Message-----
From: duxhelp-bounce@xxxxxxxxxxxxx [mailto:duxhelp-bounce@xxxxxxxxxxxxx] On
Behalf Of Christine Simpson
Sent: Wednesday, August 11, 2004 4:29 AM
To: duxhelp@xxxxxxxxxxxxx
Subject: [duxhelp] Re: DBT 10.5 Beta 5
Thanks Peter for this explanation. However, taking into account what you
are saying, I am still unhappy with the behaviour of some styles.
To test:
Try creating a file which says:
Chapter one
The Arrival.
It was almost midnight when the horse and carriage drew up in front of the
old house and the six tired, hungry children scrambled out.
Next, apply heading one style to the first line.
Apply heading 2 style to the second line.
Use the pbefore the words it was...
Now look at the codes and translate it for confirmation of what is
happening.
The only way that I have been able to use h1 h2 h3 etc styles today has been
to manually insert the ending code.
Hope you can replicate what is happening. Some styles such as the t.note63
have worked quite ok.
I have not tested but could it have something to do with nested styles?
Regards and thanks
Christine
At 05:49 PM 8/11/04, you wrote:
>Christine,
>
>This may have to do with some of my work "new" to beta 5, more than
>with Caryn's macros.
>
>Many codes will force a new line in coded view. For example, the [<]
>code does this. Often, as with [<] the code itself is left at the end
>of the previous line. It is forced there because people think of it as
>a code that ends a line, rather than one that starts a line.
>
>Other codes (e.g. [p]) force a new line but are placed at the start of
>the new line, rather than at the end of the old line. We put it there
>because people think of [p] as a code that starts a new paragraph,
>rather than one that ends the old formatting construct (whatever it might
be).
>
>Now, when you are moving through a file using the right arrow key in
>coded view, DBT simply moves the internal file position from one
>character code to the next -- always in a sequence that corresponds
>exactly with the sequence in the underlying file. At each stop along
>the way, it must put the cursor somewhere.
>
>In the case of codes that cluster to line ends (such as [<]) the cursor
>is placed just to the left of where the code itself is rendered.
>Caryn's macros thus notice the relationship between the cursor and the
>code, and read the code.
>
>Earlier in the DBT 10.5 pre-release cycle, we tried doing the same
>thing with the other type of line ending code (e.g. [p]). That is, we
>put the cursor at the start of the new line. However, this caused a
>very odd behavior. Consider a document that looks like the following in
coded view:
>
>[p]This is paragraph 1, which is not quite complet [p]This is paragraph
>2.
>
>You may wish to go back and add the "e." at the end of the first paragraph.
>To do so, you must position the cursor between the "t" and the "[p]" --
>that is, in a real sense, on the "[p}". However, if we show the cursor
>on the second line when you do this, then, as you start typing, you'll
>find that letters are added to the first line, while the cursor blinks
>away on the second.
>
>This behavior is very different from what was the story in DBT 10.4.
>In DBT
>10.4 -- and now in DBT 10.5 -- we position the cursor at the end of the
>first line to avoid this issue.
>
>Now, it would be possible to revert to the cursor positioning from the
>earlier DBT 10.5. But I prefer not to do that. If Caryn is able to
>revise her macros to handle this case (even though she didn't create
>the problem), I think we'll all be happier.
>
>- Peter
>
>-----Original Message-----
>From: duxhelp-bounce@xxxxxxxxxxxxx
>[mailto:duxhelp-bounce@xxxxxxxxxxxxx] On Behalf Of Christine Simpson
>Sent: Wednesday, August 11, 2004 12:30 AM
>To: duxhelp@xxxxxxxxxxxxx
>Subject: [duxhelp] DBT 10.5 Beta 5
>
> Hi All,
>
>Further to my earlier note directed mainly to you Karen,
>
>I find that the Alt9 in a DXB file is working as it should and giving
>good information. (I think that my JFW may just have been slow to pick
>up the new script).
>
>Re the wrong codes being read with jfw5, this is still sometimes the case.
>It seems to overlook the first code in a string of codes. If this
>first code is deleted it reads spaces instead of the codes. It seems
>that if the first code is the last to be deleted in a string of codes,
>things read much better. However, it seems that the cursor is being
>placed on the second code in a string, not the first.
>
>Also, and far more importantly: I am having difficulty in using styles.
>
>I have for example 10 lines of text.
>
>I want the first to be in h1 style, the second to be in h2 style and
>the third to indent as it is the beginning of the paragraph.
>
>When I highlight what will be h1 text and apply the style, the closing
>code is not being spoken, or I think shown.
>
>When I apply the h2 to the next line, the closing h1 then appears.
>However, there is no closing h2 code and so, all remaining text (with
>the exception of the new paragraph line which is preceeded with the [p]
>code is still being treated as heading 2 code and indenting each line
>to cell 5 (as our template English Australian, blocks h2 text to cell
five).
>
>I hope all this makes sense to you as it is long and confusing to explain.
>
>Regards and thanks
>
>Christine
>
>
>
>
> * * * * *
>Christine Simpson
>Information Alternatives
>Accessing The Information You Need
>18 Prosper Parade
>Glen Iris VIC 3146
>AUSTRALIA
>Tel: 61 3 9889 0392
>Mob: 0418 331 506
>Fax: 61 3 9889 6286
>Email: simpsonc@xxxxxxxxxxxxxx
>
>
>* * *
>* This message is via list duxhelp at freelists.org.
>* To unsubscribe, send a blank message with
>* unsubscribe
>* as the subject to <duxhelp-request@xxxxxxxxxxxxx>. You may also
>* subscribe, unsubscribe, and set vacation mode and other subscription
>* options by visiting //www.freelists.org. The list archive
>* is also located there.
>* Duxbury Systems' web site is http://www.duxburysystems.com
>* * *
>
>* * *
>* This message is via list duxhelp at freelists.org.
>* To unsubscribe, send a blank message with
>* unsubscribe
>* as the subject to <duxhelp-request@xxxxxxxxxxxxx>. You may also
>* subscribe, unsubscribe, and set vacation mode and other subscription
>* options by visiting //www.freelists.org. The list archive
>* is also located there.
>* Duxbury Systems' web site is http://www.duxburysystems.com
>* * *
* * * * *
Christine Simpson
Information Alternatives
Accessing The Information You Need
18 Prosper Parade
Glen Iris VIC 3146
AUSTRALIA
Tel: 61 3 9889 0392
Mob: 0418 331 506
Fax: 61 3 9889 6286
Email: simpsonc@xxxxxxxxxxxxxx
* * *
* This message is via list duxhelp at freelists.org.
* To unsubscribe, send a blank message with
* unsubscribe
* as the subject to <duxhelp-request@xxxxxxxxxxxxx>. You may also
* subscribe, unsubscribe, and set vacation mode and other subscription
* options by visiting //www.freelists.org. The list archive
* is also located there.
* Duxbury Systems' web site is http://www.duxburysystems.com
* * *
* * *
* This message is via list duxhelp at freelists.org.
* To unsubscribe, send a blank message with
* unsubscribe
* as the subject to <duxhelp-request@xxxxxxxxxxxxx>. You may also
* subscribe, unsubscribe, and set vacation mode and other subscription
* options by visiting //www.freelists.org. The list archive
* is also located there.
* Duxbury Systems' web site is http://www.duxburysystems.com
* * *
Other related posts:
