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

[Wolfgang Qual]

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