[Info-vax] terminal fallback tables

[Stephen Hoffman]

On 2015-03-07 21:49:08 +0000, jirkak737 at gmail.com said:

>> 
>> The TFF macros, needed to make your own fallback table, are not available in
>> STARLET.MLB or LIB.MLB libraries.  You'd need a copy of the source listings
>> to get the TFF$MACROS module or the TFF$STURCTURES.LIS (a listing containing
>> the SDL describing the TFF structure).
>> 
> 
> Mr. VAXman, Jan-Erik, Stephen, Craig, and JF,thank you for your 
> answers. Unfortunately, my issue is still unresolved. :-(
> Sometimes it make sense to leave files intact, and to process file data 
> as they are, then just convert charset on the user interface. You can 
> share data with windows, mac, unix or other clients or servers using 
> samba or NFS(both directions) or have data stored on VMS in usupported 
> charset because of aged multi-layer application. To be able to work 
> with such files using VMS utilities, a charset conversion using tff 
> seems to be a general-purpose solution. Why not to use available vms 
> solution doing exactly what we need ?

OK, but character conversions almost inherently come with their own 
forms of pain.   More than a few are not reversible, for instance.

Might also want to look at OS X, which adopted native UTF-8 support 
throughout; an approach which avoids much of the morass of fallbacks 
and translations that OpenVMS went through.  OS X also chose to use 
tools that can open and read and write the Windows documents using the 
document's native format, what would be akin to the long-deprecated CDA 
converter libraries in OpenVMS and in DECwindows.  With UTF-8-capable 
graphics displays, most characters can be displayed directly, too.

> Last week I restarted my project "8bit charsets support in VMS", it was 
> ten years postponed in a bottom of a drawer. Now, it is the best time 
> to make progress. The aim is to support any single-byte 8bit charset in 
> terminal utilities and applications. That is why I need to make 
> additional tff tables, and looking for an information how to build them.
> 
> BTW, UTF8, UCS2 and UCS2BE encodings are the next steps as so as 
> support in rms and the file system. I'd like to be able to work using 
> VMS utilities with any file encoding saved from windows notepad. 
> Fortunately, a lot of work is already done in Asian VMS variants, but 
> full unicode support, it still will be a very long travel. (see 
> Supporting the Chinese, Japanese, and Korean Languages in the OpenVMS 
> Operating System 
> http://www.dtjcd.vmsresource.org.uk/pdfs/dtj_v05-03_1993.pdf)

That internationalization work was largely done in the DEC regional 
offices, and — other than some pieces of the supporting infrastructure 
— there wasn't a whole lot of related work performed in OpenVMS 
Engineering in Nashua.  AFAIK, none of the details of that 
internationalization work were particularly documented outside of DEC, 
and pretty much all of that work involved access to the OpenVMS sources 
and the DECwindows sources.  So TFF is just the tip of the undocumented 
icebergs, here.

The language variants also disappeared from the pricebooks and from 
customer systems a long time ago, too — there aren't many left that 
recall them.  The last versions were around DECwindows V1.2-3 or so, 
IIRC.

FWIW, 1993 was also just before Windows NT Affinity really got rolling, 
and the start of recommendations to migrate away from OpenVMS.   DEC 
largely shifted over to Windows as a result of that, both as a 
front-end, and also for various back-end processing.

> OK, let me see... I've already gotten a very specific (and correct) answer...
> There are the only 35 items in the tff library... I'd bet a beer that 
> these tables were made by a collection of dcl procedures or similar 
> home-grown tool not able to be published (or may be lost).I'll try to 
> do it the same way using TFF$MACROS or maybe I'll write my own compiler.
> I'll post an outcome.

More likely, what was available for TFF either wasn't quite ready for 
documentation and support, or there were no plans to document and 
support the tables, or there were plans for some future release and 
that follow-on project was never scheduled or never completed.

Most of the tools in that era were (and very likely are still) checked 
into the source code control system — the Alpha port only tripped over 
a few widgets that weren't available and checked in.  (GNM was one of 
those, and that tool ended up getting rewritten and then released as 
Freeware, but I digress.)  The source listings will get you the details 
and very likely all of what you need to roll your own TFF tables.

I'd also definitely look to use iconv and friends, and would probably 
avoid the TFF bits — compatibility with the older VT terminals is going 
to limit your options, where X and such has rather more flexibility 
here.  You're probably going to spend as much time bringing TFF 
forward, as what iconv and friends already provide, too.

But in general, I'd suggest you not continue with your current 
approach, and make direct contact with VSI — see if they're interested 
in working with you, here.


-- 
Pure Personal Opinion | HoffmanLabs LLC