[fpc-devel] utf8 in 2.6.0

I am trying to figure out how to do that, or what I do wrong. I found a page about $codepage, but it did not help http://wiki.freepascal.org/LCL_Unicode_Support I didnt find the fpc specific page, if exists (I suspect it does) I am calling a function "function Foo(A:string)" {$mode objfpc}{$H+

Re: [fpc-devel] utf8 in 2.6.0

On 15.12.2012 19:35, Martin wrote: I am trying to figure out how to do that, or what I do wrong. I found a page about $codepage, but it did not help http://wiki.freepascal.org/LCL_Unicode_Support I didnt find the fpc specific page, if exists (I suspect it does) The page is this: http://wiki.fre

Re: [fpc-devel] utf8 in 2.6.0

On 15.12.2012 21:35, Martin wrote: I am trying to figure out how to do that, or what I do wrong. I found a page about $codepage, but it did not help http://wiki.freepascal.org/LCL_Unicode_Support I didnt find the fpc specific page, if exists (I suspect it does) I am calling a function "functi

Re: [fpc-devel] utf8 in 2.6.0

Am 18.12.2012 14:47, schrieb Anton Kavalenka: On 15.12.2012 21:35, Martin wrote: I am trying to figure out how to do that, or what I do wrong. I found a page about $codepage, but it did not help http://wiki.freepascal.org/LCL_Unicode_Support I didnt find the fpc specific page, if exists (I sus

Re: [fpc-devel] utf8 in 2.6.0

On 15 Dec 2012, at 19:35, Martin wrote: > I am trying to figure out how to do that, or what I do wrong. I found a page > about $codepage, but it did not help > http://wiki.freepascal.org/LCL_Unicode_Support > I didnt find the fpc specific page, if exists (I suspect it does) > > > I am calling

Re: [fpc-devel] utf8 in 2.6.0

On 01/01/2013 13:18, Jonas Maebe wrote: On 15 Dec 2012, at 19:35, Martin wrote: I am trying to figure out how to do that, or what I do wrong. I found a page about $codepage, but it did not help http://wiki.freepascal.org/LCL_Unicode_Support I didnt find the fpc specific page, if exists (I sus

Re: [fpc-devel] utf8 in 2.6.0

On 01 Jan 2013, at 15:14, Martin wrote: > On my hardware it is normally all fine, but fails if I add the $codepage. I > could spent a lot of work boiling that down to a sample. But given that I > couldn't even find the docs what I really should expect, Without a {$codepage xxx} directive, stri

Re: [fpc-devel] utf8 in 2.6.0

On 01/01/2013 14:24, Jonas Maebe wrote: On 01 Jan 2013, at 15:14, Martin wrote: On my hardware it is normally all fine, but fails if I add the $codepage. I could spent a lot of work boiling that down to a sample. But given that I couldn't even find the docs what I really should expect, Witho

Re: [fpc-devel] utf8 in 2.6.0

On 01 Jan 2013, at 15:40, Martin wrote: > ok, leaves me with my original problem. > > On said ppc, using the original file (no codepage directive). file should be > identical (svn checkout) (yet on 2nd thought I can't be sure, that it wasn't > open in an editor and saved with utf8 bom...). >

Re: [fpc-devel] utf8 in 2.6.0

On Tuesday 01 January 2013 15:24:05 Jonas Maebe wrote: > On 01 Jan 2013, at 15:14, Martin wrote: > > On my hardware it is normally all fine, but fails if I add the $codepage. > > I could spent a lot of work boiling that down to a sample. But given that > > I couldn't even find the docs what I reall

Re: [fpc-devel] utf8 in 2.6.0

On 01 Jan 2013, at 16:31, Martin Schreiber wrote: > On Tuesday 01 January 2013 15:24:05 Jonas Maebe wrote: >> Without a {$codepage xxx} directive, string constants containing characters >>> #127 remain exactly as they appear in the source code. >> >> With a {$codepage xxx} directive, string cons

Re: [fpc-devel] utf8 in 2.6.0

On Tuesday 01 January 2013 16:44:28 Jonas Maebe wrote: > On 01 Jan 2013, at 16:31, Martin Schreiber wrote: > > On Tuesday 01 January 2013 15:24:05 Jonas Maebe wrote: > >> Without a {$codepage xxx} directive, string constants containing > >> characters > >> > >>> #127 remain exactly as they appear i

Re: [fpc-devel] utf8 in 2.6.0

On Tuesday 01 January 2013 16:54:21 Martin Schreiber wrote: > So > " > UnicodeStringVariable:= 'abcdäüö'; > " > always will call a conversion function? > And how works " {$codepage 8859-1} ... UnicodeStringVar:= 'abcd'#228#246#252#1092#1080#1089#1074; " ? Martin

Re: [fpc-devel] utf8 in 2.6.0

On 01 Jan 2013, at 16:54, Martin Schreiber wrote: > On Tuesday 01 January 2013 16:44:28 Jonas Maebe wrote: >> The strings are stored as ansistrings with the appropriate code page. >> > So > " > UnicodeStringVariable:= 'abcdäüö'; > " > always will call a conversion function? The assignment node

Re: [fpc-devel] utf8 in 2.6.0

Thanks, another question, or is the behavior already documented? > > UnicodeStringVar:= 'abcd'#228#246#252#1092#1080#1089#1074; > > > > " > > ? > > That string contains codepoints > #255 and hence is a unicodestring rather > than a single byte string. No conversion at either compile or run time >

Re: [fpc-devel] utf8 in 2.6.0

On 01 Jan 2013, at 17:51, Martin Schreiber wrote: > Thanks, another question, or is the behavior already documented? What you are asking about has always been the same. I don't know to what extent it is documented. > {$codepage utf8} > ... > UnicodeStringVar:= 'abcd'#228#252#246; > > Does it

Re: [fpc-devel] utf8 in 2.6.0

On Tuesday 01 January 2013 18:00:59 Jonas Maebe wrote: > > I have no idea how anything I wrote suggests that it wouldn't. As > mentioned, the only difference is that string constants containing > characters >#127 are no longer always converted to unicodestring constants > at compile time. They are

Re: [fpc-devel] utf8 in 2.6.0

Jonas Maebe schrieb: And how works " {$codepage 8859-1} ... UnicodeStringVar:= 'abcd'#228#246#252#1092#1080#1089#1074; " ? That string contains codepoints > #255 and hence is a unicodestring rather than a single byte string. No conversion at either compile or run time happens, and the codepag

Re: [fpc-devel] utf8 in 2.6.0

On Tuesday 01 January 2013 18:36:01 Martin Schreiber wrote: > > So #n or #nn or #nnn or # or #n always means Unicode codepoint and > will be at compiletime converted to an 8bit character sequence depending on > {$codepage} and stored in a cpstrnew with the codepage of {$codepage} if > assig

Re: [fpc-devel] utf8 in 2.6.0

On 05 Jan 2013, at 10:29, Martin Schreiber wrote: > Are these stupid questions? No, but I seem to be unable to explain how it works since you keep asking about things I already tried to explain before, but I clearly failed to do properly. I can keep repeating myself, but I'm not sure whether t

Re: [fpc-devel] utf8 in 2.6.0

On 05.01.2013 11:30, Jonas Maebe wrote: For example, I said that basically nothing changed in 2.7.x compared to 2.6.x, except that certain string constants are no longer automatically converted to utf-16 at compile time, and then you ask "Or should we not touch the theme strings and FPC anymor

Re: [fpc-devel] utf8 in 2.6.0

On Saturday 05 January 2013 11:42:29 Sven Barth wrote: > On 05.01.2013 11:30, Jonas Maebe wrote: > > For example, I said that basically nothing changed in 2.7.x compared to > > 2.6.x, except that certain string constants are no longer automatically > > converted to utf-16 at compile time, and then

Re: [fpc-devel] utf8 in 2.6.0

On 05 Jan 2013, at 12:16, Martin Schreiber wrote: > On Saturday 05 January 2013 11:42:29 Sven Barth wrote: >> I think it was more meant in the context of the mailing list instead of >> a technical context. Like in "we had this topic a thousand times and >> maybe it's better we shut up about it no

Re: [fpc-devel] utf8 in 2.6.0

On Saturday 05 January 2013 12:39:21 Jonas Maebe wrote: > > Then maybe I should just stop completely answering any questions about > this, because apparently not answering completely enough to your liking > gets interpreted as telling you to shut up or getting moderated. Just like > Sven I don't un

Re: [fpc-devel] utf8 in 2.6.0

On Sat, 5 Jan 2013, Martin Schreiber wrote: On Saturday 05 January 2013 12:39:21 Jonas Maebe wrote: Then maybe I should just stop completely answering any questions about this, because apparently not answering completely enough to your liking gets interpreted as telling you to shut up or get

Re: [fpc-devel] utf8 in 2.6.0

On Saturday 05 January 2013 13:01:44 Michael Van Canneyt wrote: > > Seeing that you have already invested lots of time in FPC, you could also > ask yourself > > 'How can I help improve fpc so it remains the right tool for my purposes' ? > > Or have you decided that cooperation with the FPC team is

Re: [fpc-devel] utf8 in 2.6.0

On 15 December 2012 18:35, Martin wrote: > I am trying to figure out how to do that, or what I do wrong. I found a > page about $codepage, but it did not help http://wiki.freepascal.org/** > LCL_Unicode_Support > I didnt find the fpc specific page,

Re: [fpc-devel] utf8 in 2.6.0

Martin Schreiber schrieb: but I fear we can not use that information for development with Free Pascal because: " The string is represented internally as a Unicode string encoded as UTF-16. Characters in the Basic Multilingual Plane (BMP) take 2 bytes, and characters not in the BMP require 4 b

Re: [fpc-devel] utf8 in 2.6.0

On Sat, 5 Jan 2013 13:06:42 + Frank Church wrote: >[...] > It is obvious that Unicode is not a simple topic and among FPC/Lazarus > developers/contributors,I suspect that few if any at all, have a detailed > grasp of how it all hangs together in the current state of implementation. > It bring

Re: [fpc-devel] utf8 in 2.6.0

> For Lazarus: > - works with fpc 2.6.x and 2.7.1 > - LCL and most code expect ansistrings to hold UTF-8. > - pascal sources, lfm, po files are stored in UTF-8 without BOM. > Special care has to be taken, when using widestrings/unicodestring. > - there are UTF-8 functions and classes (most in pac

Re: [fpc-devel] utf8 in 2.6.0

On 5 January 2013 13:39, Mattias Gaertner wrote: > On Sat, 5 Jan 2013 13:06:42 + > Frank Church wrote: > > >[...] > > It is obvious that Unicode is not a simple topic and among FPC/Lazarus > > developers/contributors,I suspect that few if any at all, have a detailed > > grasp of how it all h

Re: [fpc-devel] utf8 in 2.6.0

Martin Schreiber schrieb: but I fear we can not use that information for development with Free Pascal because: " The string is represented internally as a Unicode string encoded as UTF-16. Characters in the Basic Multilingual Plane (BMP) take 2 bytes, and characters not in the BMP require 4 b