8 replies to this topic

[TomEck]

I have tried to set up several shorthands using a non-break space like "§ " while the space behind the § character would be a non-break space, so that, for example, "§ 7" could not be separated at a end of a line. This works fine as long as I don't use a dot in front of the non-break space in the expansion like "p.". In this case the result is that SC insert a second dot at the end of the expansion like "p. ." (still inserting the non-break space correctly).

How could I prevent the second dot?

I have tried to use the delete/backspace function but this doesn't work and I haven't found an answer in the manual or forum...

Thanks,
Thomas

[Evan Gross]

TomEck, on Nov 7 2008, 09:23 AM, said:

I have tried to set up several shorthands using a non-break space like "§ " while the space behind the § character would be a non-break space, so that, for example, "§ 7" could not be separated at a end of a line. This works fine as long as I don't use a dot in front of the non-break space in the expansion like "p.". In this case the result is that SC insert a second dot at the end of the expansion like "p. ." (still inserting the non-break space correctly).

How could I prevent the second dot?

I have tried to use the delete/backspace function but this doesn't work and I haven't found an answer in the manual or forum...

Thanks,
Thomas

Never heard of this one before. Can you give me a concrete example? The exact abbreviation/expanion pair, and exactly what you type (including the separator you use to trigger), along with any expansion options (suppress separator, match case - all the checkboxes below the expansion), and perhaps any of the Interactive/Automatic preferences that you use? Does it matter which app you are using?

[TomEck]

Evan Gross, on Nov 8 2008, 03:43 AM, said:

TomEck, on Nov 7 2008, 09:23 AM, said:

I have tried to set up several shorthands using a non-break space like "§ " while the space behind the § character would be a non-break space, so that, for example, "§ 7" could not be separated at a end of a line. This works fine as long as I don't use a dot in front of the non-break space in the expansion like "p.". In this case the result is that SC insert a second dot at the end of the expansion like "p. ." (still inserting the non-break space correctly).

How could I prevent the second dot?

I have tried to use the delete/backspace function but this doesn't work and I haven't found an answer in the manual or forum...

Thanks,
Thomas

Never heard of this one before. Can you give me a concrete example? The exact abbreviation/expanion pair, and exactly what you type (including the separator you use to trigger), along with any expansion options (suppress separator, match case - all the checkboxes below the expansion), and perhaps any of the Interactive/Automatic preferences that you use? Does it matter which app you are using?

Of course - I have set up, for example, the shorthand "S. "which should be expanded the same way "S. " but the space behind the dot should be replaced by a non-breaking space. Typically I use this function in Word 2008 (but also in other word processors like Mellel) to save to type the Word shortcut for a non-breaking space. For that reason I have defined the shorthand by marking the phrase in Word 2008 (that means I have captured the non-breaking space from Word 2008) with the "New Shorthand for Selection" function of SC. For the reason that any abbreviation should be expanded this way I don't use a special trigger; just after I hit the space bar SC replaces the abbreviation (as said, it is just to replace a normal space with a non-breaking space).

I have attached a small movie which shows the issue in Mellel (for the shorthands "S. " and "Abs. .") and will send you screenshots of my settings to your support email address (the file size is to big so that I can't attache them here...).

I haven't noticed that this is related just to a single application. It occurs definitely in Word 2008, Mellel, Mail, Textedit, and VoodooPad.

Let me know if I could assist you further or if I should send you a file with some of the problematic shorthands (I guess I can find a file with the shorthands in the library...).

Thomas

Attached Files

•  Example_SC_in_Mellel.mov   22.23K   10 downloads

[Evan Gross]

TomEck, on Nov 8 2008, 05:34 AM, said:

Of course - I have set up, for example, the shorthand "S. "which should be expanded the same way "S. " but the space behind the dot should be replaced by a non-breaking space. Typically I use this function in Word 2008 (but also in other word processors like Mellel) to save to type the Word shortcut for a non-breaking space. For that reason I have defined the shorthand by marking the phrase in Word 2008 (that means I have captured the non-breaking space from Word 2008) with the "New Shorthand for Selection" function of SC. For the reason that any abbreviation should be expanded this way I don't use a special trigger; just after I hit the space bar SC replaces the abbreviation (as said, it is just to replace a normal space with a non-breaking space).

I have attached a small movie which shows the issue in Mellel (for the shorthands "S. " and "Abs. .") and will send you screenshots of my settings to your support email address (the file size is to big so that I can't attache them here...).

I haven't noticed that this is related just to a single application. It occurs definitely in Word 2008, Mellel, Mail, Textedit, and VoodooPad.

Let me know if I could assist you further or if I should send you a file with some of the problematic shorthands (I guess I can find a file with the shorthands in the library...).

Thomas

Yeah, I can reproduce this. It's (an obscure) bug, and I can't think of a good work-around right this second. There may be one, but I think trying to get the results you want this way isn't going to work. For one, white space in abbreviations gets stripped from the beginning and end when it's added - this is because white space is always a trigger. There are various reasons this is done (mainly to deal with the linguistics internal to Spell Catcher), so an alternative method needs to be found. The fact that an extra period is appended is for sure my bug, but even with that fixed what you're doing isn't going to work.

I'll have to take a closer look, I'll let you know what I find out.

[TomEck]

Evan Gross, on Nov 8 2008, 12:40 PM, said:

TomEck, on Nov 8 2008, 05:34 AM, said:

Of course - I have set up, for example, the shorthand "S. "which should be expanded the same way "S. " but the space behind the dot should be replaced by a non-breaking space. Typically I use this function in Word 2008 (but also in other word processors like Mellel) to save to type the Word shortcut for a non-breaking space. For that reason I have defined the shorthand by marking the phrase in Word 2008 (that means I have captured the non-breaking space from Word 2008) with the "New Shorthand for Selection" function of SC. For the reason that any abbreviation should be expanded this way I don't use a special trigger; just after I hit the space bar SC replaces the abbreviation (as said, it is just to replace a normal space with a non-breaking space).

I have attached a small movie which shows the issue in Mellel (for the shorthands "S. " and "Abs. .") and will send you screenshots of my settings to your support email address (the file size is to big so that I can't attache them here...).

I haven't noticed that this is related just to a single application. It occurs definitely in Word 2008, Mellel, Mail, Textedit, and VoodooPad.

Let me know if I could assist you further or if I should send you a file with some of the problematic shorthands (I guess I can find a file with the shorthands in the library...).

Thomas

Yeah, I can reproduce this. It's (an obscure) bug, and I can't think of a good work-around right this second. There may be one, but I think trying to get the results you want this way isn't going to work. For one, white space in abbreviations gets stripped from the beginning and end when it's added - this is because white space is always a trigger. There are various reasons this is done (mainly to deal with the linguistics internal to Spell Catcher), so an alternative method needs to be found. The fact that an extra period is appended is for sure my bug, but even with that fixed what you're doing isn't going to work.

I'll have to take a closer look, I'll let you know what I find out.

Thanks for your prompt reply and the information. I am not sure if I understand you correctly because what I am trying to do works fine with other shorthands, as I have mentioned. SC replaces, for example, "§ " correctly with a "§<non-breaking space>" in Word 2008. So why would avoid the second period shouldn't fix the problem? However, I will wait patiently whether you could find a way to fix this issue...

Thanks,
Thomas

[Evan Gross]

TomEck, on Nov 8 2008, 07:00 AM, said:

Thanks for your prompt reply and the information. I am not sure if I understand you correctly because what I am trying to do works fine with other shorthands, as I have mentioned. SC replaces, for example, "§ " correctly with a "§<non-breaking space>" in Word 2008. So why would avoid the second period shouldn't fix the problem? However, I will wait patiently whether you could find a way to fix this issue...

Thanks,
Thomas

I looked a little more carefully - it's actually not my bug. This is all behaving correctly and as-designed. It's just that you're trying to do something unusual, and it involves both ending periods and whitespace characters. Problem is, both are considered very significant linguistically, and shorthands must comply with linguistic rules in Spell Catcher. This is so shorthand expansions will do the right thing when beginning a sentence, match capitalization rules according to the abbreviation, properly consider abbreviated words that require an ending dot (i.e. and etc. for example). Shorthand expansions take into account spelling rules for the language you are using - for instance French has rules about what characters are valid when following an enclitic form like l', j', t' etc. Spell Catcher's shorthand expansions are smart about this, and will only expand when the full, assembled expansion conforms to the languages rules.

Anyway, it's all working as-designed. Thing its, it's not really designed to do what you're trying to do. Spell Catcher is a linguistic product at its core, and won't allow certain things that single-purpose expansion utilities will.

I tried various things, involving suppressing the separator, using the special "Key" directives to move the cursor or delete forwards or backspace. All worked as they are supposed to, but I couldn't find a combination that did what you wanted. There may well be one using shorthands, I just haven't found it.

Let's step back a bit and consider what the actual problem you're trying to solve is. These non-breaking spaces you want to insert or substitute - what is their purpose? Is it typography-related? Is to correct something that is incorrect? If I can understand the actual problem, I might be able to suggest some other way to fix it - perhaps with some other Spell Catcher feature. Often there's more than one way to get from A to B...

[TomEck]

Evan Gross, on Nov 8 2008, 01:57 PM, said:

I looked a little more carefully - it's actually not my bug. This is all behaving correctly and as-designed. It's just that you're trying to do something unusual, and it involves both ending periods and whitespace characters. Problem is, both are considered very significant linguistically, and shorthands must comply with linguistic rules in Spell Catcher. This is so shorthand expansions will do the right thing when beginning a sentence, match capitalization rules according to the abbreviation, properly consider abbreviated words that require an ending dot (i.e. and etc. for example). Shorthand expansions take into account spelling rules for the language you are using - for instance French has rules about what characters are valid when following an enclitic form like l', j', t' etc. Spell Catcher's shorthand expansions are smart about this, and will only expand when the full, assembled expansion conforms to the languages rules.

Anyway, it's all working as-designed. Thing its, it's not really designed to do what you're trying to do. Spell Catcher is a linguistic product at its core, and won't allow certain things that single-purpose expansion utilities will.

I agree that SC has to comply with linguistic rules and should what I try to do cause problems, I will use a work around or try to avoid this type of shorthands. However, the abbreviations I have set up are common (especially legal) German one which I have added to the "Learned words" list as well. For example, "S. " is the German equivalent to the English "p." (for page) and could in legal context also be used as the abbreviation for "sentence"; "Abs. " is the German equivalent to English "sec." (for section). Anyway, for the reason that this abbreviations in a legal context typically followed by a number I could set up nine shorthands instead ("S. 1" to "S. 9", "Abs. 1" to "Abs. 9").

Quote

I tried various things, involving suppressing the separator, using the special "Key" directives to move the cursor or delete forwards or backspace. All worked as they are supposed to, but I couldn't find a combination that did what you wanted. There may well be one using shorthands, I just haven't found it.

Same here. I have tried several combinations but I had always the result with the second period...

Quote

Let's step back a bit and consider what the actual problem you're trying to solve is. These non-breaking spaces you want to insert or substitute - what is their purpose? Is it typography-related? Is to correct something that is incorrect? If I can understand the actual problem, I might be able to suggest some other way to fix it - perhaps with some other Spell Catcher feature. Often there's more than one way to get from A to B...

Yep, they are more or less typography related. I use the non-breacking spaces to avoid that at a line end the following number breaks in the next line (this is in particular useful if you are writing in centre justification). Under German linguistic rules (at least used in a legal context) the mentioned abbreviations (§, Abs. , S.) could not stand at the end of a line without a connected number or, in other words, a line should not begin with a number.

Hope this makes it a bit more clear what I try to do.

Thanks for your efforts.

Thomas

[Evan Gross]

TomEck, on Nov 9 2008, 07:31 AM, said:

Yep, they are more or less typography related. I use the non-breaking spaces to avoid that at a line end the following number breaks in the next line (this is in particular useful if you are writing in centre justification). Under German linguistic rules (at least used in a legal context) the mentioned abbreviations (§, Abs. , S.) could not stand at the end of a line without a connected number or, in other words, a line should not begin with a number.

Could you give me some sort of pointer to a clear description of this particular rule? Not just in the context of getting the results you're after, but in general, as it applies to German language and/or typography rules.

Does it fall in the domain of Spell Catcher’s "Smart punctuation" features for French and Canadian French? If you're not familiar with this French-specific feature, when "Smart quotes and punctuation" is selected (Spell Catcher Preferences, Interactive pane, Automatic tab), French rules regarding the requirement of non-breaking space before/after certain punctuation marks are automatically applied.

Here's a reference on Wikipedia.

[TomEck]

Evan Gross, on Dec 29 2008, 08:15 AM, said:

Could you give me some sort of pointer to a clear description of this particular rule? Not just in the context of getting the results you're after, but in general, as it applies to German language and/or typography rules.

Does it fall in the domain of Spell Catcher’s "Smart punctuation" features for French and Canadian French? If you're not familiar with this French-specific feature, when "Smart quotes and punctuation" is selected (Spell Catcher Preferences, Interactive pane, Automatic tab), French rules regarding the requirement of non-breaking space before/after certain punctuation marks are automatically applied.

Here's a reference on Wikipedia.

First of all I would like to apologise for the delay in responding to your request.

I have searched the Internet for some references regarding the language and typographic rules I am referring to but I only found a few in electronic form and all of them are written in the German language, I am afraid.

However, this is a link to one of the sources I could find. Perhaps your linguistic software supplier can take advantage of this source (please see at the bottom of p. 6, for example). This source also refers to other sources in the English language, such as

• Bringhurst, Robert: The Elements of Typographic Style. Vancouver: Hartley & Marks, 1997;
  
• Grossman, John (Hrsg.): The Chicago Manual of Style. 14.ed. Chicago: University of Chicago Press, 1998;
  
• Tschichold, Jan: The Form of the Book: Essays on the Morality of Good Design. Vancouver: Hartley & Marks, 1991.

I don't know these sources, and so I don't know if they will provide a more detailed insight to the rules I am referring to.

The basic rule is that any abbreviation should not be disconnected at the end of a line.

Example:

The German abbreviation for "e.g." is "z. B.". In contrast to the English language there has to be a space between the two letters in the German language (z.<space>B.). If the abbreviation is located at the end of a line, the word processor will separate the two letters as long as you don't use a non-breaking space between the letters instead of a normal space.

Wrong:

Am Zeilenende dürfen
Abkürzungen wie z.
B. nicht getrennt werden.

Correct:

Am Zeilenende dürfen
Abkürzungen wie z. B.
nicht getrennt werden.

The same rule applies, as mentioned, to abbreviations such as §, Abs. (= sec.) or S. (= p.) if they are followed by a number like § 10.

Example:

Wrong:

Die sich aus §
10 des Bürgerlichen
Gesetzbuches ergebenden...


Correct:

Die sich aus § 10
des Bürgerlichen
Gesetzbuches ergebenden...

or

Die sich aus
§ 10 des Bürgerlichen
Gesetzbuches ergebenden...

For that reason, I always place a non-breaking space between abbreviations and the connected text they should not be separated from.

Does that help you a bit more?

Thomas