[Gvsig_english] gvSIG and external tables, font-encoding etc.

Francisco José Peñarrubia fjp at scolab.es
Tue Apr 7 14:23:20 CEST 2009


Wolfgang, I'm part of the gvSIG team (one of the developers).

But now we are preparing 1.9 release, and is difficult to put new 
functionalities when stabilization period. It's not a developers 
decission, so it takes time to convince other people to do some changes 
that may introduce new bugs.
If you think this is a bug, it may be easier, but is not clear if this 
is a new capability or not. Also, it may help it you test the extension 
and think it is safe (or find a problem and I will try to solve).

Also, to put code inside an official relase, it takes time and money 
(documentation to users, developers, better user interface, 
testing....). That's why this is not an official release, is easier to 
publish and the people can test it before put in the official relase.

Anyway, we are discussing about if it's good to take some risks or not. 
Maybe in a few days they will tell you if 1.9 will solve your problem.

Best regards.

PS: BTW, may vote is yes to include ;-)

Fran Peñarrubia
gvSIG Team.
www.scolab.es

Wolfgang Qual escribió:
> Hi Francisco, list and: developers.
> Great thanks to Francisco for his answers. Unfortunately, my problem is not 
> yet solved. I set the encoding on my machine to latin-1 (export LANG=...), 
> but now, it is not even possible to manually enter these german umlauts. 
> I will revert this setting. 
> I consider this encoding-issue as very important; therefore, I would like to 
> ask the gvSIG-team, whether a function (like extShalom) to set the encoding 
> will be added to gvSIG core functionality. I am really surprised that I did 
> not discover this issue before ;(
> BTW, postGIS (@Francisco) is no option for me, as I have no 
> postGIS-installation here...
>
> Best,
> Wolfgang
>
> ----8<----
> Am Dienstag 07 April 2009 10:26:21 schrieb Wolfgang Qual:
>   
>> Hi Francisco and list,
>> maybe another important information:
>> I tried the following:
>> 1) create a _new empty point-shapefile_ with only one string-colum in
>> gvSIG. 2) use the field-calculator and set all records of that column to
>> 'tae' 3) use the replace-tool in the field calculator to replace each 'tae'
>> with '_TÄ': replace([field1],'tae','_TÄ').
>> However, gvSIG will not write that 'Ä', but only a little square (on two
>> machines, one running 1.1.2 and the other 1.9 alpha something).
>> _But_ it _is_ possible to manually write 'Ä' in the table. This is very
>> strange...
>> By the way: typing "echo $LANG" on the command line will give that result:
>> de_DE.UTF-8
>> Could this setting cause these problems? Your comments are apprecitated
>> very much... I really do need these Umlauts....
>>
>> Best,
>> Wolfgang
>>
>> Am Montag 06 April 2009 12:53:58 schrieb Francisco José Peñarrubia:
>>     
>>> Hi, Wolfgang.
>>>
>>> gvSIG is well tested to work with ñ. The default enconding with PostGIS
>>> and dbf tables is LATIN1 (ISO-8859-1). To operate with dbf tables in
>>> different encodings, you may need to install extShalom plugin (from
>>> non-official extensions repository).
>>>
>>> https://gvsig.org/plugins/downloads/extshalom
>>>
>>> Best regards.
>>>
>>> Fran Peñarrubia
>>> www.scolab.es
>>>
>>> Wolfgang Qual escribió:
>>>       
>>>> Good morning everyone.
>>>> I will continue to report about my little (serious!) problems regarding
>>>> german umlauts and modifiying attribute tables in gvSIG. My table
>>>> contains values like '2344_TÄ' and I would like to replace that '_TÄ'
>>>> with 'tae'. The strange thing is that it is _possible_ to select these
>>>> values using the filter function with the expression [column_name] like
>>>> '%_TÄ'; all those values are selected - wonderful. However, when trying
>>>> to replace the questioned values using the field calculator, gvSIG
>>>> fails: nothing is replaced. It is only possible to replace the umlauts
>>>> manually. I do not understand this (reaction of gvSIG). Therefore, I
>>>> would be most grateful for some comments or _any_ ideas on how to solve
>>>> this. BTW, do you have the same problem with the spanish 'ñ'?
>>>>
>>>> Best regards,
>>>> Wolfgang
>>>>
>>>> ----8<------
>>>>
>>>> -------- Original-Nachricht --------
>>>>
>>>>         
>>>>> Datum: Thu, 2 Apr 2009 13:50:47 +0200
>>>>> Von: Wolfgang Qual <wolfgang.qual at gmx.net>
>>>>> An: Users list <gvsig_internacional at runas.cap.gva.es>
>>>>> Betreff: [Gvsig_english] gvSIG and external tables, font-encoding etc.
>>>>>
>>>>>
>>>>>
>>>>> Hi list,
>>>>> I have some remarks/questions on external tables and font-encoding
>>>>> regarding
>>>>> gvSIG 1.1.2 and the coming versions of gvSIG.
>>>>>
>>>>> * currently, it is not possible to edit external tables that were
>>>>> imported from csv. It seems, as if only dbf-files can be edited in
>>>>> gvSIG. You might say: well, do this conversion within openoffice.
>>>>> Right. But on my computer, I
>>>>> only have openoffice 2.3 installed (the official computer of my
>>>>> office) - and
>>>>> this version of calc is not able to write me a dbf-file. It simply
>>>>> crashes.
>>>>> This strange behaviour is reported as a bug in calc. I can also
>>>>> convert this
>>>>> file in excel (currently, excel is still available..), but there, I do
>>>>> not have any possibility to modify/set the font encoding.
>>>>> * Font-encoding: I do not know, which font-encoding gvSIG accepts. I
>>>>> imported
>>>>> a dbf-file that was created in Excel. This table has some values
>>>>> (text) which
>>>>> needs to be processed. To be more precise: I need to convert
>>>>> substrings like 'ae' into Ä (german umlaut). I found the function
>>>>> (replace) in the field
>>>>> calculator of gvSIG. But this will not create an 'Ä' but only a
>>>>> square-shaped
>>>>> character - I think that the font-encoding is the reason for this.
>>>>>
>>>>> Therefore, I would be really happy, if you could answer me the
>>>>> following questions:
>>>>>
>>>>> * how do you work with csv-files in gvSIG: is it really true that only
>>>>> dbf can
>>>>> be edited? Which software are you using to save files as dbf?
>>>>> * which font-encoding is used within gvSIG? Or: which encoding do you
>>>>> use when
>>>>> exporting a file from openoffice into a different format?
>>>>> * will there be a possiblity to edit tables derived from csv/txt in
>>>>> gvSIG?
>>>>>
>>>>> Best regards,
>>>>> Wolfgang
>>>>>
>>>>> _______________________________________________
>>>>> Gvsig_internacional mailing list
>>>>> Gvsig_internacional at runas.cap.gva.es
>>>>> http://runas.cap.gva.es/mailman/listinfo/gvsig_internacional
>>>>>           
>>> _______________________________________________
>>> Gvsig_internacional mailing list
>>> Gvsig_internacional at runas.cap.gva.es
>>> http://runas.cap.gva.es/mailman/listinfo/gvsig_internacional
>>>       
>> _______________________________________________
>> Gvsig_internacional mailing list
>> Gvsig_internacional at runas.cap.gva.es
>> http://runas.cap.gva.es/mailman/listinfo/gvsig_internacional
>>     
>
>
>
> _______________________________________________
> Gvsig_internacional mailing list
> Gvsig_internacional at runas.cap.gva.es
> http://runas.cap.gva.es/mailman/listinfo/gvsig_internacional
>   



More information about the Gvsig_internacional mailing list