[scribus] Automagically insert correct German quotation marks instead of manually inserting them?

Gregory Pittman gregp_ky at yahoo.com
Sun Sep 5 01:17:41 CEST 2010

On 09/04/2010 09:50 AM, Louis Desjardins wrote:
> 2010/8/29 Gregory Pittman<gregp_ky at yahoo.com>
>> On 08/18/2010 04:58 PM, a.l.e wrote:
>>> On Wed, 18 Aug 2010 19:42:51 +0200
>>> Thorsten Panknin<thp at thorstenpeh.de>   wrote:
>>>   *bump*
>>> no
>>> a.l.e
>> Here is something I've put together over the weekend:
>> http://wiki.scribus.net/index.php/Convert_Typewriter_Quotes_to_Typographic_Quotes
>> As written, it will convert typewriter quotes to typographic quotes in a
>> single selected frame. The logic is a bit kludgy, but it performs pretty
>> well. So far, you can choose English or German style quotes, others to come.
>> Do not expect it to be perfect, you will still need to scan your document to
>> see how it did, and as always, save your document just before running the
>> script.
> Hi Greg,
> I was wondering whether this was a job for Short Words?
> I have a dream that Short Words is the typographic tool we need to tackle
> many of those issues.
> In French, since the quotes are preceeded and followed by a word space, it
> might be kind of tricky to set the rules for a computer to make the
> appropriate call where a human would figure out in a fraction of a second
> what is opening and what is closing...  But we could tell the computer to
> look for the next quote and then set the first to opening and the second to
> closing. This might need much more thought...
> (I left my answer unfinished for days and now I am reading the post by Axel
> Bojer, very interesting!)
> What occurs to me is that unless there would be some coding mysteries (for
> me at least!), such tables that make such auto replacements could (should?)
> be in the Short Word table?
> We could then have a powerful tool to manage typographic rules according to
> each language (or even better, according to just any given case).
> I think that Short Words is the home for this !

Here is at least some of the trickiness that came out of writing this 
script, with its ugly tests. In the simple case, you have a left quote 
preceded by a space, and a right quote followed by a space.

However, right away, you may have a block of text which begins with a 
quote or ends with a quote, so you must deal with these.

You also have paragraphs which may begin or end with quotes. I had 
thought that I would look for some sort of 'newline' character, but it 
seems that certainly as of 1.3.8, we have a new scheme. If you look at 
the file format we now have, each paragraph is a separate block of text, 
thus from a getText point of view in scripter, you cannot test for a 
newline/new paragraph character, there is none.

You also have situations where quotes can either lead or follow 
punctuation, at least in American English.

So I ended with the very complex set of rules to end up, eliminating 
possibilities, then taking a stab at a default to follow the else: clause.

I'm hoping that with a bit more time to understand how text frames are 
built with printing and nonprinting characters I can make this less ugly.

A language like French presents 2 new problems, this business about the 
space between the double guillemets and the letter (trying to find the 
unicode for this space, which may not exist in all fonts), and that it 
quickly became impractical to place single guillemets, since there are 
so many apostrophes in French: d'etat, l'amour, and so on. Since I have 
no books in French, and also since searching the internet for display of 
typography is frustrating (first rule: there are no rules), I couldn't 
find out if the typographic apostrophe of d'etat is a curly quote or 
not. I ended up making an editorial decision to make them right curly 
quotes pending some negative feedback.

In the end, I think I have illustrated how even the mighty Short Words 
may struggle with this issue. I think there will always be a disclaimer 
about this however it's done. Doing it with zero or very few errors may 
require something along the lines of language-specific artificial 


More information about the scribus mailing list