Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: walkero on August 14, 2007, 12:56:39 PM
-
Hello to everyone. I'd like to ask you where can I find the encoding files that are needed to make AFAOS 3.96 work with ttf and greek letters. I tried the the same files that I used with TTManager, but it didn't work, so I cannot see greek letters. Do you have any clue?
-
It would interest me too. So far I have not been able to display central European letters using AfA_OS and appropriate TT fonts.
-
that stand in AFA FAQ txt.
Q: I want use unicode Fonts for other languages.
A: Make sure the truetype font support your national signs.
Select in the mainpage the codepage file.It must be a ASCII file that
use no Hex values (0x). Now select the font and click on convert. The
message "can`t copy font" can ignored when dir "Fonts:" is chosen.
-
Thanks for your replies guys...
well, i tried the following things
I used ttf that I was using with TTFtools and worked fine, with greek encoding. So these fonts support my national signs.
Then I used 3 different encoding files. I will give you part of them to tell me which is the best to use. But none of them did the work, unfortunately. All the files are for ISO-8859-7 encoding.
File #1
0xC1 0x0391 # GREEK CAPITAL LETTER ALPHA
0xC2 0x0392 # GREEK CAPITAL LETTER BETA
0xC3 0x0393 # GREEK CAPITAL LETTER GAMMA
0xC4 0x0394 # GREEK CAPITAL LETTER DELTA
0xC5 0x0395 # GREEK CAPITAL LETTER EPSILON
0xC6 0x0396 # GREEK CAPITAL LETTER ZETA
File #2
C1 0391
C2 0392
C3 0393
C4 0394
C5 0395
C6 0396
File #3
!C1 U+0391 Alpha
!C2 U+0392 Beta
!C3 U+0393 Gamma
!C4 U+0394 Delta
!C5 U+0395 Epsilon
!C6 U+0396 Zeta
So which is the best, or where should I find the right one?
-
that files use hex letters.
for example 0xc1 is 193
0x391 is 913
0xC1 0x0391 # GREEK CAPITAL LETTER ALPHA
correct for AFA is this
193 913 # GREEK CAPITAL LETTER ALPHA
but because MOS use the same truetype fontmanger i think if youz ask for a MOS greek codepage fiel this work in AFA too
-
Thanks for your reply again.
I thought that it might be the same with morphos, so I got from my MorphOS installation the _codepages folder form the FONTS: and tried that one. Unfortunately, it didn't work, and also the encoding files look like this:
0x41 0x0041 # LATIN CAPITAL LETTER A
0x42 0x0042 # LATIN CAPITAL LETTER B
0x43 0x0043 # LATIN CAPITAL LETTER C
0x44 0x0044 # LATIN CAPITAL LETTER D
0x45 0x0045 # LATIN CAPITAL LETTER E
0x46 0x0046 # LATIN CAPITAL LETTER F
0x47 0x0047 # LATIN CAPITAL LETTER G
Is there somewhere a site where I could download the needed encoding files? Or should I make the changes by hand?
-
Well, I just made the transformation by hand and worked just fine. But there should be a place where someone could download these encoding files. Is there anywhere to do that?
Thanks for your time and help.
-
does this mean MOS support files with hex content ?
I thought MOS is same as AROS because MOS team should exchange files with AROS team.the diskfont stuff of MOS and AROS is same.
But if MOS work with hex codepages, and they dont want exchange the files, seem i must add this feature, because there are no codepages here
maybe you can ask if somebody send you the actual MOS source of the truetype manager to save me time ?
-
@bernd_afa
I thought MOS is same as AROS because MOS team should exchange files with AROS team.the diskfont stuff of MOS and AROS is same.
While AROS has accepted many of our contributions, it doesn't mean they'll just merge all our changes blindly. As a result there are differences between AROS and MorphOS, even for the components shared. That is why you can't share ft .otag files between AROS and MorphOS for example (AROS for some unknown reason renamed the freetype bullet engine from "ft2" to "freetype2").
But if MOS work with hex codepages, and they dont want exchange the files, seem i must add this feature, because there are no codepages here
maybe you can ask if somebody send you the actual MOS source of the truetype manager to save me time ?
As AROS ftmanager is directly based on the MorphOS ftmanager, you already have it.
BTW: The codepage files are available at Unicode, Inc ftp server (http://ftp://ftp.unicode.org/Public/MAPPINGS/).
-
The code i have is this.It work only with dec values.
or is MOS strtolong enhanced that strtolong support too hex values ?
BOOL LoadCodePage(const char *filename)
{
BOOL ret = FALSE;
BPTR file;
UBYTE buf[256];
SetDefaultCodePage();
file = Open(filename, MODE_OLDFILE);
if (file)
{
ret = TRUE;
while (FGets(file, buf, sizeof(buf)))
{
STRPTR p = buf;
LONG index, unicode;
LONG chars;
if (*p == '#')
continue;
chars = StrToLong(p, &index);
if (chars <= 0 || index < 0 || index > 255)
continue;
p += chars;
chars = StrToLong(p, &unicode);
kprintf ("%d %d\n",codepage[index],unicode);
if (chars <= 0)
continue;
codepage[index] = (UWORD)unicode;
}
Close(file);
}
return ret;
}
here is code of aros strtolong
{
AROS_LIBFUNC_INIT
AROS_LIBBASE_EXT_DECL(struct DosLibrary *,DOSBase)
LONG sign=0, v=0;
CONST_STRPTR s=string;
/* Skip leading whitespace characters */
if(*s==' '||*s=='\t')
s++;
/* Swallow sign */
if(*s=='+'||*s=='-')
sign=*s++;
/* If there is no number return an error. */
if(*s<'0'||*s>'9')
{
*value=0;
return -1;
}
/* Calculate result */
do
v=v*10+*s++-'0';
while(*s>='0'&&*s<='9');
/* Negative? */
if(sign=='-')
v=-v;
/* All done. */
*value=v;
return s-string;
AROS_LIBFUNC_EXIT
} /* StrToLong */
-
@bernd_afa
is MOS strtolong enhanced that strtolong support too hex values ?
Yes.
-
and source is not available ?
I look a little in ansi c libs, the command strtol seem work too in hex and dec.only syntax is diffrent.but maybe can wrap
does somebody know if strtolong on OS4 too work with hex ?
I prefer to enhance strtolong then because it is usefull when support too hex values
-
@bernd_afa
and source is not available ?
To my knowledge AROS has the source-code for this function, along with other dos.library parts which were derived from AROS. Perhaps it wasn't merged for some reason?
-
is MOS strtolong enhanced that strtolong support too hex values ?
Yes.
Was that a good idea considering that autodocs say "Converts decimal string into LONG value."?
-
I am sure they add the feature that hex is support and change the autodoc when they not went down 1994 ;-)
I think it is usefull for coding that strtolong support also other input formats.
So in parser can use hex and decimal values.
there is a ansi command strtol.
but when i look on this, i see it is not so easy to get the number of the character in the value.
-
@Georg
Was that a good idea considering that autodocs say "Converts decimal string into LONG value."?
It automagically gave hex support for ReadArgs /N, too, so yes I consider it a good move.
Also, to specify a hex number you need a identifier before such number, thus I can't possibly see any disadvantages in it either.
-
It automagically gave hex support for ReadArgs /N, too, so yes I consider it a good move.
Also, to specify a hex number you need a identifier before such number, thus I can't possibly see any disadvantages in it either.
Backwards compatibility. If you have a function which takes an input string and splits it into int_number and string_remainder then a input string "0x10Hello" would give
0 x10Hello
in the old AOS style implementation (not accepting hex), but
would give
16 Hello in the new MOS style implementation (accepting hex).
Okay, I would probably (have) to think much harder for an example which makes some more (any) sense, but OTOH how likely do you think it is that a similiar enhancement is ever done for clib/atoi() and why.
-
When i read this then maybe it is safer to let stringtolong as it is and change fontmanager.
but i am lazy and cant test if codepages work, because default font support german correct.
@Georg,
Do you have MOS source with stringtolong ?
I do it in a separate command.
-
@Georg
Backwards compatibility
Considering the AROS StrToLong() isn't AmigaOS compatible either, that is a bit silly argument IMO.
OTOH how likely do you think it is that a similiar enhancement is ever done for clib/atoi() and why.
Never.
-
Piru wrote:
Considering the AROS StrToLong() isn't AmigaOS compatible either, that is a bit silly argument IMO.
Well, if so (which is very likely after a quick look at the source: for example the space/tab check should be in a loop I guess), it's because of buggy implementation not intended implementation.
Never.
And why?
-
bernd_afa wrote:
Do you have MOS source with stringtolong ?
I do it in a separate command.
No, we only have DOS sources from 2001 or 2002 which did not yet have hex support in. It's not something hard to implement but I would rather change ftmanager to use strtol() instead. Because for running ftmanager under AOS using StrToLong() would only work if you patch it to work like MOS.
-
@Georg
And why?
Well, you know why, but lets go into details, just for fun.
Because atoi() is ANSI, C89, C99 etc. It's a standard function. In short: I don't feel like touching such standard function, which should be pretty obvious.
I consider StrToLong() to be less standard, and subject to change, as long as the original functionality isn't compromised. It obviously is a calculated risk to change the behaviour, but this is one of the smallest changes in MorphOS. There are many more fundamental ones. I have no problem changing functionality if it offers new and improved features. However, it should happen in a way that it breaks as little old behaviour as possible. Staying in the confines of the original AmigaOS 3.1 API doesn't just cut it for me (or us the MorphOS Team in general).
In this StrToLong()-case the positivies are: Having old applications automagically support hex numbers when reading numbers via StrToLong() and ReadArgs() /N. Negatives: Potentially breaking some applications that depend on the call stopping on hex identifier. So far I haven't seen myself, or heard of any reports that would indicate any software breaking due to this change.
As a funny remark, some seem to have had broken atoi (http://www.thinkage.ca/english/gcos/expl/c/lib/atoi.html) at some point.
-
Ok on MOS this is less risc, because it is not 100% compatible so all 68k programs work and Coders must port their programs if they notice a bug when they test all functions.
AFA should be 100% compatible.
I think too there cant be a 100% garantie that there is none of the 10000 and more programs out that fail in some cases, maybe read bad load file only when option x and y is set and program do wired things.
As Georg told, AROS Team have no source of the new strtolong.
Can you please send it ?
-
@bernd_afa
As Georg told, AROS Team have no source of the new strtolong.
The particular change was made in 2002. Georg himself had access to the source code at that time.
Can you please send it ?
This code is licensed under AROS Public License v1.1 (http://aros.sourceforge.net/license.html).
/*
(C) 1995-96 AROS - The Amiga Research OS
(C) 2002 Sigbjørn "CISC" Skjæret and Harry "Piru" Sintonen
$Id: strtolong.c,v 1.1.1.1 2005/03/15 15:54:40 laire Exp $
Desc: Convert a string into a long
Lang: english
*/
#include "dos_intern.h"
#define DEBUG_STRTOLONG(x) ;
/*****************************************************************************
NAME */
#include <proto/dos.h>
#include "dos_intern.h"
AROS_LH2I(LONG, StrToLong,
/* SYNOPSIS */
AROS_LHA(STRPTR, string, D1),
AROS_LHA(LONG *, value, D2),
/* LOCATION */
struct DosLibrary *, DOSBase, 136, Dos)
/* FUNCTION
Convert a string to a long number.
INPUTS
string - The value to convert
value - The result is returned here
RESULT
How many characters in the string were considered when it was
converted or -1 if no valid number could be found.
NOTES
The routine doesn't check if the number if too large.
EXAMPLE
// Valid number are: 5, -1, +3, +0007, $feed, -0xBEEF, etc.
BUGS
SEE ALSO
INTERNALS
HISTORY
04-07-02 Added ability to read hex-strings.
*****************************************************************************/
{
AROS_LIBFUNC_INIT
AROS_LIBBASE_EXT_DECL(struct DosLibrary *,DOSBase)
LONG old_v, v = 0;
STRPTR s = string;
BOOL negative = FALSE;
DEBUG_STRTOLONG(dprintf("StrToLong: string \"%s\" value 0x%lx\n", string, (ULONG) value));
/* Skip leading whitespace characters */
while (*s == ' ' || *s == '\t')
++s;
/* Swallow sign */
#ifdef AROS_DOS_COMPATIBLE
if (*s == '-')
#else
if (*s == '+' || *s == '-')
#endif
negative = *s++ == '-';
/* Is it a hex-string? */
if (*s == '$' || (*s == '0' && (s[1] == 'x' || s[1] == 'X')))
{
LONG i = 0;
/* Skip hex-identifier */
if (*s++ != '$')
++s;
/* If there is no number return an error. */
if ((*s < '0' || *s > '9') && (*s < 'a' || *s > 'f') && (*s < 'A' || *s > 'F'))
{
*value = 0;
DEBUG_STRTOLONG(dprintf("StrToLong: no number, return error\n"));
/* Compatability return */
if (s[-1] == 'x' || s[-1] == 'X')
return s - 1 - string;
else
return -1;
}
/* Calculate result */
do
{
old_v = v;
v <<= 4;
if (negative && v < old_v)
break;
old_v = v;
v += ((*s <= '9') ? (*s - '0') : ((*s <= 'F') ? (*s - 'A' + 10) : (*s - 'a' + 10)));
if (negative && v == -2147483648L)
{
negative = FALSE;
old_v = v;
++s;
break;
}
else if (negative && v < old_v)
break;
++s;
if (++i == 8) break;
} while ((*s >= '0' && *s <= '9') || (*s >= 'a' && *s <= 'f') || (*s >= 'A' && *s <= 'F'));
}
else
{
/* If there is no number return an error. */
if (*s < '0' || *s > '9')
{
*value = 0;
DEBUG_STRTOLONG(dprintf("StrToLong: no number, return error\n"));
return -1;
}
/* Calculate result */
do
{
LONG x;
x = v;
old_v = v;
v <<= 3;
if (v < old_v)
break;
old_v = v;
v += x;
if (v < old_v)
break;
old_v = v;
v += x;
if (v < old_v)
break;
old_v = v;
v = v + *s - '0';
if (negative && v == -2147483648L)
{
negative = FALSE;
old_v = v;
++s;
break;
}
else if (v < old_v)
break;
++s;
} while (*s >= '0' && *s <= '9');
}
/* Overflow? */
if (v < old_v)
v = old_v;
/* Negative? */
if (negative)
v = -v;
/* All done. */
*value = v;
DEBUG_STRTOLONG(dprintf("StrToLong: *value = %ld return %ld\n", v, (LONG) (s - string)));
return s - string;
AROS_LIBFUNC_EXIT
} /* StrToLong */
-
Piru wrote:
The particular change was made in 2002. Georg himself had access to the source code at that time.
cvs access I had did not include dos sources. DOS sources from 2001 or 2002 were sent as archive by Emm (initial plan was to have final thing compilable for both AROS and MOS from same source (reason for added AROS_DOS_COMPATIBLE) but at end Emm/MOS coders did not have enough time and/or possibility to test)).
-
@Piru
Many thanks for the source
-
On AFA Page is new fontmanager, i add the code Piru send and rename it as MosStrToLong.source is included in that archive
please look if that work.if so, then the fontmanager is datet as non beta
The link to codepage files is too on AFA page or look here