>>>>> Rugxulo <rugx...@gmail.com> writes:
>>>>> On Mon, Aug 27, 2012 at 5:12 AM, Ivan Shmakov wrote:
>>>>> Rugxulo <rugx...@gmail.com> writes:
[…]
>> Once, I've written a document which, while for the most part
>> cyrillic, included more than a few passages in English and Latin.
>> It's not a problem, as the latter two could be encoded in pure ASCII
>> (as long as one doesn't care about, say, ae and oe), and thus all
>> its extensions, but I guess that one of my future documents is
>> likely to contain a few passages in Esperanto just as well, so…
> My point was that Unicode isn't always available in a host OS (or
> apps),
OS comprises a kernel, a set of libraries, and the applications.
It's not a problem if the kernel has only weak, or no, support
for Unicode — Linux supports encodings only for filesystem and
VT access, AIUI. Neither it's an unsolvable problem if the
libraries bundled have none — as the applications may rely on
their own facilities for Unicode support.
> and software that demands Unicode compliance is a bit too stringent,
> IMHO, esp. when most people couldn't care less what encoding is used
> for their text as long as it does the job.
> BTW, you can use E-o in pure ASCII too. The "official" solution is
> to use gh, ch, sh, hh, jh but nothing extra for 'u(', just plain 'u'.
> Thus, it's easier to mechanically change, sort, etc. if you use
> (unofficial) gx, cx, sx, hx, jx, ux instead.
Indeed, I know about these conventions.
[…]
>>> Or just need the end resulting encoding to be in popular,
>>> compatible format? If only the latter, copy and paste and iconv /
>>> recode etc. is sufficient.
>> Sufficient, yes. Convenient, I doubt it.
> I know, I'm just saying, instead of throwing out the baby with the
> bathwater (and crazily considering all non-Unicode OSes like DOS as
> obsolete, which some people do),
If Bloček supports Unicode, and comes with FreeDOS, then I'd say
that FreeDOS /has/ support for Unicode.
> it's more practical to do with such workarounds, esp. when Unicode
> isn't a "hard" (technical) requirement.
In the long term, such workarounds doesn't seem practical.
[…]
>>> Do you want me to repack it in .7z for you?
>> Yes, please.
> Okay, gimme a few minutes to double-check it, and then I'll upload it
> to iBiblio.
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/edit/blocek/
ACK, thanks! I've now downloaded the file, and going to test it
later this day.
[…]
> I get the vague impression that RAR would maybe let 2.x owners
> upgrade to 3.x for free (though keyfile changed), but I'm not sure
> about the reverse, esp. for 3.x-only owners. In other words, if
> Laaca really wants to use RAR, I guess we should politely ask
> (without demanding) that he use 2.x methods,
… Or to use some another archiver.
> but I don't know if that's practical or realistic here. I also
> halfway want to try (and probably fail, sigh) to compile Unar with
> DJGPP's Objective C, but you said it wasn't mostly successful even
> under Linux. :-/
Yes.
>>> Most around here aren't as idealistic enough to avoid all
>>> proprietary things. (I doubt any of us uses a Lemote MIPS a la
>>> RMS, much less exclusively!)
>> Well, neither do I use SeaBIOS (or TianoCore.) But using a
>> proprietary archiver while the free software ones are so widespread
>> is somewhat off the limits for me.
> So you'd rather do without? (Not me!) Blame the developer, heh.
> Actually, don't blame anyone. Use a workaround. Or just suck it up
> and use "close enough" UNRAR 3.x. I know that's not ideal, but it's
> a far from ideal world!!
Well, I don't think I'd have the time to do it regularly, but
would I have it, I'd rather re-pack the Bloček releases to some
free software-compatible format and make it available to the
community, so that no one else has to use proprietary software
to install (or study, modify, etc.) Bloček.
>>> If you want to edit Unicode in DOS, you have several options,
>>> e. g. GNU Emacs 23.3 (DJGPP), Mined, Blocek, etc.
>> Don't they all use VGA (EGA) text modes (and thus 256 or 512 glyphs
>> at one time)?
> No. GNU Emacs (Unicode internally since 23.x) just displays
> digraphs, e. g. "C>" for "C with circumflex".
Even if the glyph is available in the font currently loaded?
Doesn't it have M-x set-terminal-coding-system? Perhaps I'd try
it myself.
> Mined will now color the "C" blue to show that it's different (though
> if you use FreeDOS' cp853, you can see it properly, e. g. "mined -u"
> will edit as UTF-8 but display correctly under cp853). Both of those
> have internal E-o "x metodo" support (easier to use, IMO) while
> Blocek relies on external KEYB ('^' [chgjs] or AltGr 'u').
ACK, thanks for the information.
> Actually, I hate to admit, but I've never really used Blocek much for
> anything heavy, and I now notice that it doesn't even display
> properly for me on this particular computer (Intel gfx?), seems to be
> "unintentionally" split screen. ;-)
I guess I still have a few PCI (and even ISA) VGA-compatible
adapters in my disposal.
--
FSF associate member #7257 http://sf-day.org/
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
