ARIS Express erronously handles accented characters in pdf reports?

Hi Péter,

thank you for your message. I will forward this to our development.

Bye,

Frank

Hi Péter,

did you use hungarian as attribute language & output language of your report? In this case the correct codepage should be used for PDF generation.

BR,

Torsten

You are welcome, Frank. (There is a hope for an elf at your help/service desk already started a checkout on the case.) I am interested in the result. Certainly any further insight should the developers need, I offer my experience as end-user support. Good luck!  Péter

Hi Torsten!

Do you mean by 'attribute language' the regional setting of XP? There I set up Hungarian as default language. At run time, when we start the pdf generation I have not known any tuning option about. I assumed the regional setting should be transparent for each application.

There is no problem at all with ARIS Express at data entry phase. Model development in hungarian enjoys full comfort. Just this output tricks us a bit :) .

Thank you! Péter

Hi Peter.

please check the following, and I think that is what Torsten is talking about:

Please set the "modeling language" in the options (view -> options).

If you want to test it, unfortunatly, you need to create a new model, because this change only affects new models.

Bye,

Frank

Thank you both, Torsten & Frank,

with your guidance I arranged a first rendezvous :-) with Model language.

I have not even realized so far, that it exist at all.

Well, the language setting has originally been set to Hungarian. I made a new model to follow your hint in practice: no change in the pdf-generation behaviour indicated.

Once I had a suspicion for a while, that my approach -I used ARIS Express as a restricted user- might have caused this problem. To get an evidence, I logged in the PC as admin and made a model  in that environment: the same positive result was achieved in term of accented character loss.

Your support is worth, thank you! Most certainly, this is a very low-priority problem,. I can cope with my modeling challenges. I am sure the developers will soon figure out the reason , when they look into depth of code.

Kind regards, Péter

Info to the developer team (via Frank).

Meanwhile I browsed character set/code table definition pages and I picked a promising information: Root of the problem may likely be that some component uses Latin-1 code table instead of Latin-2. Such an error would exactly result loss of this "őŐűŰ" characters, what my original post indicated.

I'm trustin this indeed can get us nearer to sorting out the issue.

Kind regards: Peter