× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Let me state for the record that there is little here that I disagree with BUT - I _have_ to produce printer output - it is _not_ an option. The client has already made the decision and I understand their rationale.

End of story.


On 2014-09-03, at 10:32 PM, John Yeung <gallium.arsenide@xxxxxxxxx> wrote:

On Wed, Sep 3, 2014 at 4:32 PM, Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:
I agree that it would be better - as would many, many other options. But I'm stuck with printer files and nothing else.

I was hoping that more people here had had experience in globalizing their applications and had some thoughts on how best to handle printer files.

I think what people *with* experience are saying is that the best way
to handle printer files is to do away with them. Birgitta gave a
concrete strategy for using printer files, to which you said

I was rather afraid of that Birgitta, the only other option then seems to be to take the approach that Booth did and load the fields in the logic, but that's not a good solution either.

The best available solution isn't always a good solution. In your
position, it seems like "something that works" is better than anything
that doesn't work.

Also, I disagree strongly with this:

I can't believe that printer support is so poor compared with displays - particularly since green screen are dying - but printer could go on forever.

I mean, I agree with the part about printer support being poor
compared with display support. I disagree that green screens are
dying any faster than printer output. Where I work, print is pretty
much dead. There is definitely no new development in print output,
yet there's still a continual stream of green screen development.
Even where we *need* printed output for whatever reason, there are
replacement options for printer files (DocPath, ACOM, and the like).
With the group of developers we have, it's been easier to learn other
forms of output than other forms of interactive user interface. There
has actually also been more demand from our users for electronic
output (usually Excel) than demand for a different UI (especially from
our long-in-the-tooth users who have gotten freakishly proficient with
green screens).

Finally, regardless of how easy or hard it is to learn other UI
technologies and paradigms, in large existing systems, it's easier to
replace printer files one by one in organic fashion than it is to
replace a display file here and a display file there.

John Y.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.