Marc Bavant skribis: > >> Marc Bavant skribis: >> >>> Kaj B2 kaj B2/3 sxajnas al mi tre konvenaj. Cetere la du sistemoj >>> povas kunvivi, cxar kiam la nomoj koincidas, ankaux la signoj >>> koincidas, do eble ni petu de Wieland, ke li bv enkonduki la entojn >>> de ambaux. Kompreneble la redaktilo devas fari elekton, ne gravas al >>> mi kiun. >> Pro ĝiaj pli mallongaj nomoj, mi preferas B2/3 al B2. > > Bone.
Se ne estas obĵetoj de aliaj ReVuloj, ni konsideru B2/3 interkonsentita. > >> Mi ne rekomendas subteni pli ol unu formo, ĉar alikaze perdiĝus la >> unusenceco de la transformado. > > Nu, unusenceco ne sxajnas al mi tute deviga. Se la redaktilo bezonas > specialan subaron de la entoj por havi veran bijekcion inter la signoj kaj > la entoj, ni povas uzi por gxi tiun subaron kaj lasi la homan uzanton uzi > pli vastan sistemon. > Esence vi pravas: El la vidpunkto de XML-traktiloj la transformado estas ĉiam unusenca, eĉ se ni havas plurajn samvalorajn entojn. La problemo estas iom specifa por ReVo, ĉar ial oni difinis la 7bit-puran, "entan" formon kiel "kanonan" kaj sekve, la redaktilo provas reprodukti tian formon el la malkoditaj unikodaj signoj. En ĉi tiaj situacioj, unusencaj nomoj garantias, ke "rondvetura" transformado ĉiam produktas formon identan al la origino. Tio estas tre utila kiam oni ekzamenas versiojn de dosieroj por trovi la (verajn) diferencojn. Plursencaj signonomoj ne havas tiun econ kaj foje rezultigas formojn malsamajn. Tiuj fals-pozitivoj estas iom ĝenaj. >> Por plene establigi la unusencecon, mi eĉ rekomendus elimini la tri >> "nenormajn mallongigojn". Aliflanke, certe temas pri mallongigoj tre >> konvenaj por arabaj tradukoj, kaj ni jam havis ilin ankaŭ en nia ĝisnuna >> sistemo. Tial ni prezervu ilin, kondiĉe ke la redaktilo (kaj aliaj >> programoj) havu la liberecon, malkombini ilin kaj uzi la fundamentajn >> signojn. > > Principe, mi tute konsentas, sed tio ne rilatas nur al niaj entoj. Kiam iu > redaktanto tajpas "b�+fatha+alif", estas supozeble, ke la redaktilo ricevos > tiujn tri signojn. Ni povas lasi gxin libera produkti "a_ba;a_fatha;a_A;" > aux "a_ba;a_fatha_A;" (cxar la programo facile povus sxangxi "a_fatha;a_A;" > al "a_fatha_A;"). Miaopinie la redaktilo prefere kodu la ricevitajn signojn unuope kaj ne provu trovi mallongigajn entojn por signosekvencoj. Tio estas la plej simpla konduto, kaj plej verŝajne tiel funkcias la redaktilo en sia nuna formo. Bv. noti ke igi la redaktilon preferi mallongigitajn formojn ne solvus la problemon de plursenseco: ĉi-kaze perdiĝus la mane entajpitaj entoj por unuopaj signoj. > Mi tamen havas dubon pri tio, kio okazas, kiam iu tapjpas > "alif+hamza_sure". Ja povas esti, ke Windows mem transformas tion al la > kombina signo U+0623. Estus bone antauxvidi direktivon por doni al la > redaktilo, cxu konservi la kombinajn signojn, aux dividi ilin en konsisterojn. Tio dependus de la pelilo. La peliloj en Windows kaj Linux ne faras tion. Plej verŝajne nek la peliloj de Mac. Estus ja strange se peliloj transformus inter unikode ekvivalentaj signoj kaj signo-sekvencoj (ä, é, أ, ...), ĉar tiel ne plu eblus entajpi/ricevi unun el la du formoj. Amike, Behnam
