Hello

Does TTCN-3 provide any means to divide up a long FreeText string on
several lines without changing contents of the string? If I am
deep within indentation, or I have a very long attribute, log message,
or action strings, I might like to write it on several lines to avoid
exceeding 80 characters.

Example:
..
{
..
{
action("The quick brown fox jumped over the lazy dog, and this line is
too long")
}
..
}
..


If I split it like

{
action("The quick brown fox jumped over the lazy dog,
and this line is too long")
}


then the string is not the same, because there is a new line character
plus lots of spaces before the "and".

The concatenation operator & cannot be used within FreeText and with
action/log/encode to write

action("The quick brown fox jumped over the lazy dog," &
"and this line is too long")


What if the BNF part

478. FreeText ::= """ {ExtendedAlphaNum} """


was defined as

478. FreeText ::= {""" {ExtendedAlphaNum} """}+


which would allow writing of

action("The quick brown fox jumped over the lazy dog,"
"and this line is too long"),


which would be the same as
"The quick brown fox jumped over the lazy dog, and this line is too long"

BR
Antti

Hi Antti,

I never understood, what the rationale is behind the restriction
of log and action to character strings appearing literally in the
invocation of the respective statement. It could not be too difficult
to allow expressions there, that evaluate to character strings.

In any case, for action, you could do the following:

template charstring fox :=
"The quick brown fox jumped over the lazy dog,"
& " and this line is too long";

and later

action (fox);

Regards,
Matthias

--
Requirements visualized. Implementation simplified.
Bridging the gaps with requirements-driven development.
See us at Embedded World 2004: www.telelogic.com/embedded-world2004

Dr. Matthias Jung
Senior Consultant Professional Services

Telelogic Deutschland GmbH, Otto-Brenner-Str. 247 , 33604 Bielefeld, Germany
Phone: +49 (521) 14503-33
Fax: +49 (521) 14503-50
Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.


Telelogic - Automating the development lifecycle!

---

The information contained in this e-mail, including any attachment or
enclosure, is intended only for the person or entity to which it is
addressed and may contain confidential material.
Any unauthorised use, review, retransmissions, dissemination, copying
or other use of this information by persons or entities other than
the intended recipient is prohibited.

---

---

Ursprüngliche Nachricht

---

Von: Antti Hyrkkanen [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Gesendet: Freitag, 13. Februar 2004 16:25
An: This email address is being protected from spambots. You need JavaScript enabled to view it.
Betreff: Question on FreeText and line breaks


Hello

Does TTCN-3 provide any means to divide up a long FreeText string on
several lines without changing contents of the string? If I am
deep within indentation, or I have a very long attribute, log message,
or action strings, I might like to write it on several lines to avoid
exceeding 80 characters.

Example:
..
{
..
{
action("The quick brown fox jumped over the lazy dog, and this line is
too long")
}
..
}
..


If I split it like

{
action("The quick brown fox jumped over the lazy dog,
and this line is too long")
}


then the string is not the same, because there is a new line character
plus lots of spaces before the "and".

The concatenation operator & cannot be used within FreeText and with
action/log/encode to write

action("The quick brown fox jumped over the lazy dog," &
"and this line is too long")


What if the BNF part

478. FreeText ::= """ {ExtendedAlphaNum} """


was defined as

478. FreeText ::= {""" {ExtendedAlphaNum} """}+


which would allow writing of

action("The quick brown fox jumped over the lazy dog,"
"and this line is too long"),


which would be the same as
"The quick brown fox jumped over the lazy dog, and this line is too long"

BR
Antti

Hi all,

CR 244 Improved log statements will allow logging expressions and templates. Agreed in principle some smoothing of the concrete text for the standard still has to be done.

Regarding action the opposite has happened. Resolution of CR 155 resulted that only strings are allowed. But action is meant for the human tester only, so text is natural (for any machine interface you shall simply use a port). But to allow text concatenation, textual constants and variables is something to be considered.

Gyorgy

>

---

Original Message

---

> From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
> [This email address is being protected from spambots. You need JavaScript enabled to view it.]On Behalf Of Matthias Jung
> Sent: Friday, February 13, 2004 4:49 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: AW: Question on FreeText and line breaks
>
>
> Hi Antti,
>
> I never understood, what the rationale is behind the restriction
> of log and action to character strings appearing literally in the
> invocation of the respective statement. It could not be too difficult
> to allow expressions there, that evaluate to character strings.
>
> In any case, for action, you could do the following:
>
> template charstring fox :=
> "The quick brown fox jumped over the lazy dog,"
> & " and this line is too long";
>
> and later
>
> action (fox);
>
> Regards,
> Matthias
>
> --
> Requirements visualized. Implementation simplified.
> Bridging the gaps with requirements-driven development.
> See us at Embedded World 2004: www.telelogic.com/embedded-world2004
>
> Dr. Matthias Jung
> Senior Consultant Professional Services
>
> Telelogic Deutschland GmbH, Otto-Brenner-Str. 247 , 33604
> Bielefeld, Germany
> Phone: +49 (521) 14503-33
> Fax: +49 (521) 14503-50
> Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
>
>
> Telelogic - Automating the development lifecycle!
>
>
>

---

> The information contained in this e-mail, including any attachment or
> enclosure, is intended only for the person or entity to which it is
> addressed and may contain confidential material.
> Any unauthorised use, review, retransmissions, dissemination, copying
> or other use of this information by persons or entities other than
> the intended recipient is prohibited.
>

---

>
>

---

Ursprüngliche Nachricht

---

> Von: Antti Hyrkkanen [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Gesendet: Freitag, 13. Februar 2004 16:25
> An: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Betreff: Question on FreeText and line breaks
>
>
> Hello
>
> Does TTCN-3 provide any means to divide up a long FreeText string on
> several lines without changing contents of the string? If I am
> deep within indentation, or I have a very long attribute, log message,
> or action strings, I might like to write it on several lines to avoid
> exceeding 80 characters.
>
> Example:
> ..
> {
> ..
> {
> action("The quick brown fox jumped over the lazy dog,
> and this line is
> too long")
> }
> ..
> }
> ..
>
>
> If I split it like
>
> {
> action("The quick brown fox jumped over the lazy dog,
> and this line is too long")
> }
>
>
> then the string is not the same, because there is a new line character
> plus lots of spaces before the "and".
>
> The concatenation operator & cannot be used within FreeText and with
> action/log/encode to write
>
> action("The quick brown fox jumped over the lazy dog," &
> "and this line is too long")
>
>
> What if the BNF part
>
> 478. FreeText ::= """ {ExtendedAlphaNum} """
>
>
> was defined as
>
> 478. FreeText ::= {""" {ExtendedAlphaNum} """}+
>
>
> which would allow writing of
>
> action("The quick brown fox jumped over the lazy dog,"
> "and this line is too long"),
>
>
> which would be the same as
> "The quick brown fox jumped over the lazy dog, and this line
> is too long"
>
> BR
> Antti
>

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

Hi

What about attributes? The codec system has to parse/recognize
the text string, and it would be nice to be able to split
the attribute string on several lines to make it more
human readable in the TTCN-3 modules, without changing
the contents of the string.

variant (reference)
"bignendian,16-bit,nopadding,yetanotherparameter,onemoreoption,oncemore";

variant (reference) "bignendian,
16-bit,
nopadding,
yetanotherparameter,
onemoreoption,
oncemore";

If my dummy codec does not understand white space, then
it wont recognize the latter variant attribute.

---

Original Message

---

From: "ext György Réthy (IJ/ETH)" <This email address is being protected from spambots. You need JavaScript enabled to view it.>
To: <This email address is being protected from spambots. You need JavaScript enabled to view it.>
Sent: 13 February, 2004 18:06
Subject: Re: Question on FreeText and line breaks


Hi all,

CR 244 Improved log statements will allow logging expressions and templates.
Agreed in principle some smoothing of the concrete text for the standard
still has to be done.

Regarding action the opposite has happened. Resolution of CR 155 resulted
that only strings are allowed. But action is meant for the human tester
only, so text is natural (for any machine interface you shall simply use a
port). But to allow text concatenation, textual constants and variables is
something to be considered.

Gyorgy

>

---

Original Message

---

> From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
> [This email address is being protected from spambots. You need JavaScript enabled to view it.]On Behalf Of Matthias Jung
> Sent: Friday, February 13, 2004 4:49 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: AW: Question on FreeText and line breaks
>
>
> Hi Antti,
>
> I never understood, what the rationale is behind the restriction
> of log and action to character strings appearing literally in the
> invocation of the respective statement. It could not be too difficult
> to allow expressions there, that evaluate to character strings.
>
> In any case, for action, you could do the following:
>
> template charstring fox :=
> "The quick brown fox jumped over the lazy dog,"
> & " and this line is too long";
>
> and later
>
> action (fox);
>
> Regards,
> Matthias
>
> --
> Requirements visualized. Implementation simplified.
> Bridging the gaps with requirements-driven development.
> See us at Embedded World 2004: www.telelogic.com/embedded-world2004
>
> Dr. Matthias Jung
> Senior Consultant Professional Services
>
> Telelogic Deutschland GmbH, Otto-Brenner-Str. 247 , 33604
> Bielefeld, Germany
> Phone: +49 (521) 14503-33
> Fax: +49 (521) 14503-50
> Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
>
>
> Telelogic - Automating the development lifecycle!
>
>
>

---

> The information contained in this e-mail, including any attachment or
> enclosure, is intended only for the person or entity to which it is
> addressed and may contain confidential material.
> Any unauthorised use, review, retransmissions, dissemination, copying
> or other use of this information by persons or entities other than
> the intended recipient is prohibited.
>

---

>
>

---

Ursprüngliche Nachricht

---

> Von: Antti Hyrkkanen [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Gesendet: Freitag, 13. Februar 2004 16:25
> An: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Betreff: Question on FreeText and line breaks
>
>
> Hello
>
> Does TTCN-3 provide any means to divide up a long FreeText string on
> several lines without changing contents of the string? If I am
> deep within indentation, or I have a very long attribute, log message,
> or action strings, I might like to write it on several lines to avoid
> exceeding 80 characters.
>
> Example:
> ..
> {
> ..
> {
> action("The quick brown fox jumped over the lazy dog,
> and this line is
> too long")
> }
> ..
> }
> ..
>
>
> If I split it like
>
> {
> action("The quick brown fox jumped over the lazy dog,
> and this line is too long")
> }
>
>
> then the string is not the same, because there is a new line character
> plus lots of spaces before the "and".
>
> The concatenation operator & cannot be used within FreeText and with
> action/log/encode to write
>
> action("The quick brown fox jumped over the lazy dog," &
> "and this line is too long")
>
>
> What if the BNF part
>
> 478. FreeText ::= """ {ExtendedAlphaNum} """
>
>
> was defined as
>
> 478. FreeText ::= {""" {ExtendedAlphaNum} """}+
>
>
> which would allow writing of
>
> action("The quick brown fox jumped over the lazy dog,"
> "and this line is too long"),
>
>
> which would be the same as
> "The quick brown fox jumped over the lazy dog, and this line
> is too long"
>
> BR
> Antti
>

This communication is confidential and intended solely for the addressee(s).
Any unauthorized review, use, disclosure or distribution is prohibited. If
you believe this message has been sent to you in error, please notify the
sender by replying to this transmission and delete the message without
disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption,
interruption, unauthorized amendment, tampering and viruses, and we only
send and receive e-mails on the basis that we are not liable for any such
corruption, interception, amendment, tampering or viruses or any
consequences thereof.

Hi,

The solution is simple. Your codec shall recognize and process white spaces.

Gyorgy

>

---

Original Message

---

> From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
> [This email address is being protected from spambots. You need JavaScript enabled to view it.]On Behalf Of Antti Hyrkkanen
> Sent: Friday, February 13, 2004 5:30 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Question on FreeText and line breaks
>
>
> Hi
>
> What about attributes? The codec system has to parse/recognize
> the text string, and it would be nice to be able to split
> the attribute string on several lines to make it more
> human readable in the TTCN-3 modules, without changing
> the contents of the string.
>
> variant (reference)
> "bignendian,16-bit,nopadding,yetanotherparameter,onemoreoption
> ,oncemore";
>
> variant (reference) "bignendian,
> 16-bit,
> nopadding,
> yetanotherparameter,
> onemoreoption,
> oncemore";
>
> If my dummy codec does not understand white space, then
> it wont recognize the latter variant attribute.
>
>

---

Original Message

---

> From: "ext György Réthy (IJ/ETH)" <This email address is being protected from spambots. You need JavaScript enabled to view it.>
> To: <This email address is being protected from spambots. You need JavaScript enabled to view it.>
> Sent: 13 February, 2004 18:06
> Subject: Re: Question on FreeText and line breaks
>
>
> Hi all,
>
> CR 244 Improved log statements will allow logging expressions
> and templates.
> Agreed in principle some smoothing of the concrete text for
> the standard
> still has to be done.
>
> Regarding action the opposite has happened. Resolution of CR
> 155 resulted
> that only strings are allowed. But action is meant for the
> human tester
> only, so text is natural (for any machine interface you shall
> simply use a
> port). But to allow text concatenation, textual constants and
> variables is
> something to be considered.
>
> Gyorgy
>
> >

---

Original Message

---

> > From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
> > [This email address is being protected from spambots. You need JavaScript enabled to view it.]On Behalf Of Matthias Jung
> > Sent: Friday, February 13, 2004 4:49 PM
> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Subject: AW: Question on FreeText and line breaks
> >
> >
> > Hi Antti,
> >
> > I never understood, what the rationale is behind the restriction
> > of log and action to character strings appearing literally in the
> > invocation of the respective statement. It could not be too
> difficult
> > to allow expressions there, that evaluate to character strings.
> >
> > In any case, for action, you could do the following:
> >
> > template charstring fox :=
> > "The quick brown fox jumped over the lazy dog,"
> > & " and this line is too long";
> >
> > and later
> >
> > action (fox);
> >
> > Regards,
> > Matthias
> >
> > --
> > Requirements visualized. Implementation simplified.
> > Bridging the gaps with requirements-driven development.
> > See us at Embedded World 2004: www.telelogic.com/embedded-world2004
> >
> > Dr. Matthias Jung
> > Senior Consultant Professional Services
> >
> > Telelogic Deutschland GmbH, Otto-Brenner-Str. 247 , 33604
> > Bielefeld, Germany
> > Phone: +49 (521) 14503-33
> > Fax: +49 (521) 14503-50
> > Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >
> >
> > Telelogic - Automating the development lifecycle!
> >
> >
> >
>

---

> > The information contained in this e-mail, including any
> attachment or
> > enclosure, is intended only for the person or entity to
> which it is
> > addressed and may contain confidential material.
> > Any unauthorised use, review, retransmissions,
> dissemination, copying
> > or other use of this information by persons or entities
> other than
> > the intended recipient is prohibited.
> >
>

---

> >
> >

---

Ursprüngliche Nachricht

---

> > Von: Antti Hyrkkanen [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> > Gesendet: Freitag, 13. Februar 2004 16:25
> > An: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Betreff: Question on FreeText and line breaks
> >
> >
> > Hello
> >
> > Does TTCN-3 provide any means to divide up a long FreeText string on
> > several lines without changing contents of the string? If I am
> > deep within indentation, or I have a very long attribute,
> log message,
> > or action strings, I might like to write it on several
> lines to avoid
> > exceeding 80 characters.
> >
> > Example:
> > ..
> > {
> > ..
> > {
> > action("The quick brown fox jumped over the lazy dog,
> > and this line is
> > too long")
> > }
> > ..
> > }
> > ..
> >
> >
> > If I split it like
> >
> > {
> > action("The quick brown fox jumped over the lazy dog,
> > and this line is too long")
> > }
> >
> >
> > then the string is not the same, because there is a new
> line character
> > plus lots of spaces before the "and".
> >
> > The concatenation operator & cannot be used within FreeText and with
> > action/log/encode to write
> >
> > action("The quick brown fox jumped over the lazy dog," &
> > "and this line is too long")
> >
> >
> > What if the BNF part
> >
> > 478. FreeText ::= """ {ExtendedAlphaNum} """
> >
> >
> > was defined as
> >
> > 478. FreeText ::= {""" {ExtendedAlphaNum} """}+
> >
> >
> > which would allow writing of
> >
> > action("The quick brown fox jumped over the lazy dog,"
> > "and this line is too long"),
> >
> >
> > which would be the same as
> > "The quick brown fox jumped over the lazy dog, and this line
> > is too long"
> >
> > BR
> > Antti
> >
>
> This communication is confidential and intended solely for
> the addressee(s).
> Any unauthorized review, use, disclosure or distribution is
> prohibited. If
> you believe this message has been sent to you in error,
> please notify the
> sender by replying to this transmission and delete the message without
> disclosing it. Thank you.
>
> E-mail including attachments is susceptible to data corruption,
> interruption, unauthorized amendment, tampering and viruses,
> and we only
> send and receive e-mails on the basis that we are not liable
> for any such
> corruption, interception, amendment, tampering or viruses or any
> consequences thereof.
>

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

In einer eMail vom 16/02/2004 10:11:34 GMT Standard Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:

> Hi,

Hi Gyorgy,

What do you define as being whit spaces?

space?
Carriage return?
tabs?

Thanks,

Claude.


>
> The solution is simple. Your codec shall recognize and process white spaces.
>
> Gyorgy
>
>



Claude Desroches email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Solonplatz 3/2 phone: +49 30 9606 7986
13088 Berlin fax: +49 30 9606 7987

Germany

Hi,

It has to understood that except a few predefined values (none of them spans
over several rows and contain other white space character than pure space)
attributes are defined by users and/or tool vendors.

Therefore the specifier of attribute string(s) shall define what is a white-
space in its implementation (which characters the tool will process as white-
space characters).

My PERSONAL opinion is that for unique style the same set of characters should
be supported as white-spaces as in the core language; these are (specified
implicitly):

HORIZONTAL TABULATION (9)

LINE FEED (10)

VERTICAL TABULATION (11)

FORM FEED (12)

CARRIAGE RETURN (13)

SPACE (32)

or we could also use the ASN.1 definition: "Any formatting action that yields a
space on a printed page, such as spaces or tabs."

Gyorgy

---

Original Message

---

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
[This email address is being protected from spambots. You need JavaScript enabled to view it.]On Behalf Of Claude Desroches
Sent: Monday, February 16, 2004 5:24 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Question on FreeText and line breaks


In einer eMail vom 16/02/2004 10:11:34 GMT Standard Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:



Hi,



Hi Gyorgy,

What do you define as being whit spaces?

space?
Carriage return?
tabs?

Thanks,

Claude.





The solution is simple. Your codec shall recognize and process white spaces.

Gyorgy







Claude Desroches email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Solonplatz 3/2 phone: +49 30 9606 7986
13088 Berlin fax: +49 30 9606 7987
Germany


This communication is confidential and intended solely for the addressee(s). Any
unauthorized review, use, disclosure or distribution is prohibited. If you
believe this message has been sent to you in error, please notify the sender by
replying to this transmission and delete the message without disclosing it.
Thank you.

E-mail including attachments is susceptible to data corruption, interruption,
unauthorized amendment, tampering and viruses, and we only send and receive e-
mails on the basis that we are not liable for any such corruption, interception,
amendment, tampering or viruses or any consequences thereof.

In einer eMail vom 16/02/2004 17:07:47 GMT Standard Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:

> Thema: Re: Question on FreeText and line breaks
> Datum: 16/02/2004 17:07:47 GMT Standard Time
> Von: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Beantworten: This email address is being protected from spambots. You need JavaScript enabled to view it.
> An: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Internet-eMail:
>
>
>

Hi Gyorgy,

Thanks for the quick reply. Although this might seem to be a trivial issue,
it is
important that a consensus be achieved, to ensure portability across tools.

Could the standard (TTCN3 Core) ES 201-873-1 be enhanced to reflect this?

Seeing what has happened with ASN.1 and TTCN-2 and how, over time, they
diverged from one another, using/adopting the ASN.1 definition would help as
it
would avoid eventual problems associated with divergence between ASN.1 and
TTCN3.

However, if attribute strings can be used to specify what white space is,
then it might
not be so important. The set of characters which you define as white space
is a
good start.

Any other opinions, objections, comments from others on the list?

Cheers,

Claude.

PS: Do control characters cause a space on a printed page? What character
set
is assumed? char, universal char? other? or is this irrelevant/independent
of which
character set, so long as the definition (borrowed from ASN.1) holds true?

> Hi,
>
> It has to understood that except a few predefined values (none of them spans
> over several rows and contain other white space character than pure space)
> attributes are defined by users and/or tool vendors.
>
> Therefore the specifier of attribute string(s) shall define what is a
> white-space in its implementation (which characters the tool will process as
> white-space characters).
>
> My PERSONAL opinion is that for unique style the same set of characters
> should be supported as white-spaces as in the core language; these are
(specified
> implicitly): HORIZONTAL TABULATION (9)
>
> LINE FEED (10)
>
> VERTICAL TABULATION (11)
>
> FORM FEED (12)
>
> CARRIAGE RETURN (13)
>
> SPACE (32)
>
>
> or we could also use the ASN.1 definition: "Any formatting action that
> yields a space on a printed page, such as spaces or tabs."
>
> Gyorgy
>
> >>

---

Original Message

---

>> From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
>> [This email address is being protected from spambots. You need JavaScript enabled to view it.]On Behalf Of Claude Desroches
>> Sent: Monday, February 16, 2004 5:24 PM
>> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>> Subject: Re: Question on FreeText and line breaks
>>
>>
>> In einer eMail vom 16/02/2004 10:11:34 GMT Standard Time schreibt
>> This email address is being protected from spambots. You need JavaScript enabled to view it.:
>>
>> >>> Hi,
>>
>>
>> Hi Gyorgy,
>>
>> What do you define as being whit spaces?
>>
>> space?
>> Carriage return?
>> tabs?
>>
>> Thanks,
>>
>> Claude.
>>
>>
>> >>>
>>> The solution is simple. Your codec shall recognize and process white
>>> spaces.
>>>
>>> Gyorgy
>>>
>>>
>>
>>
>>
>> Claude Desroches email: This email address is being protected from spambots. You need JavaScript enabled to view it.
>> Solonplatz 3/2 phone: +49 30 9606 7986
>> 13088 Berlin fax: +49 30 9606 7987
>>
>> Germany
> This communication is confidential and intended solely for the addressee(s).
> Any unauthorized review, use, disclosure or distribution is prohibited. If
> you believe this message has been sent to you in error, please notify the
> sender by replying to this transmission and delete the message without
disclosing
> it. Thank you.
>
> E-mail including attachments is susceptible to data corruption,
> interruption, unauthorized amendment, tampering and viruses, and we only send
and receive
> e-mails on the basis that we are not liable for any such corruption,
> interception, amendment, tampering or viruses or any consequences thereof.
>



Claude Desroches email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Solonplatz 3/2 phone: +49 30 9606 7986
13088 Berlin fax: +49 30 9606 7987

Germany