lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev tech. question: translating strings to different charsets


From: Vlad Harchev
Subject: Re: lynx-dev tech. question: translating strings to different charsets
Date: Fri, 3 Sep 1999 06:08:13 +0500 (SAMST)

On Wed, 1 Sep 1999, Klaus Weide wrote:

> On Thu, 2 Sep 1999, Vlad Harchev wrote:
> 
> >  I started implemented support for hyphenation. I need to know how can I
> > translate the string from current charset of the document to some other, 
> > given
> > by chset handle (don't want to dig through lynx headers to discover this).
> > No entity conversion desired.
> 
> The most complete function for that is in LYCharUtils.c,
> LYUCFullyTranslateString_1 or one of the wrappers around it
> (or make a new one).
> 
> I hope you know what you mean with "current charset of the document".

 OK, now I understood that I will need the translation from display charset to
some charset (the name of which will be known after reading the lynx.cfg).
 I checked LYUCFullyTranslateString_1 - and was very upset. In order
hyphenation to work, the last word on each line, that doesn't fit on
that line, should be hyphenated. In order it to be hyphenated, it should be
translated to the charset of the hyphenation rules (that are loaded at
startup). But using this function, especially due to the fact that it uses
dynamic allocation, will take a lot CPU time. So I ask, what is more
preferable way to get rid of dynamic allocation:
1) Use UC* tables directly (may be hack them in order to do this)
2) Insure (looking at the code) or hack LYUCFullyTranslateString_1 so it won't
reallocate buffer - so it will be possible to pass pointer to static storage
to it (but it will be slow due to the generality).

PS: information about what characters are "human letters" and the mapping from
 "tolower" mapping will be included in the file with hyphenation rules, so the
  translation from one charset to another is the only performance problem I 
  see.

>    Klaus
> 

 Best regards,
  -Vlad


reply via email to

[Prev in Thread] Current Thread [Next in Thread]