Hi Denis, On Mon, Jun 25, 2012 at 6:06 PM, Denis Kudriashov <[email protected]>wrote:
> Hello. > > What is responsibility of environments (russian, japanese) classes. > Why its needed? Why converter classes not enough? > > For example, I can write russian text at workspace without setting any > specific russian environment. I only need specific fonts for this. > > Without being an expert, what I can see is that LanguageEnvironments are a kind of facade/factory of Charset, Encoding, Locales, Fonts... So, Greek environment should provide you all the correct configuration to do greek stuff... > > 2012/6/25 Guillermo Polito <[email protected]> > >> Hi guys, >> >> I'm trying to understand the Multilingual packages to get things a bit >> more reorganized. This way we can start to have a simpler and >> understandable kernel. So, >> >> - We have all environments(greek, chinese, japanese, korean, russian...) >> in the same package. Each environment has it's associated charset, and >> text converter, which are in different packages. Also, each text converter >> has a table of conversions between unicode and the encoding. But all >> converters are together, and all charsets are together. >> >> What about putting related things together? I mean, japanese converter >> with japanese environment with japanese charset in one package. Same with >> russian, korean, chinese... Does it make sense? This way we should be >> able to unload one of them if we do not really need it. >> >> - MultiByteFileStream and MultiByteBinaryOrTextStream are inside >> Multilingual-TextConversion? Even, they do the same on top of a file or a >> memory stream of bytes (or they say so in the comment :^D )... >> >> What about merging them? using a decorator? They have a lot in common... >> :/ Put them in a different package? >> >> - Just curious. ImmPlugin is working or shipped with vms? Not for macos, >> because there is no macos implementation. Then, the class comment says: >> >> *"On Windows, the plugin is not provided in the shipped VM's, and its >> current whereabouts are uncertain. >> >> On Unix, the only implemented behaviour is setting the position when >> over-the-spot precomposition of characters is the current mode. >> >> In the VM, the mode is chosen to the first available valid mode returned >> by the X Server, so whether this is actually relevant at all depends on the >> X Server.*" >> >> So, does someone use it and see value on keeping it? >> >> >> Guille >> > >
