[athen] WYNN 3.5 PDF issues

[Baker, Nick]

Cath-

            Thanks for the response. Good to know we are not alone

The sequence of events is:

In WYNN, we click "Open," then choose a PDF to open.

WYNN starts Acrobat, then opens the file within Acrobat in the
background.

Acrobat "prints" to the Freedom Import Printer in the background

The "Print" fails with the error message I reported.

(Running as root (i.e., no security) the print is successful, and WYNN
then "scans" the virtual document and delivers the PDF as a WYNN
document on screen.)

 

. Here our latest email to FS support re.: WYNN/Freedom Import Printer
issues.

 

_______________________________

      Sorry I did not respond sooner, but I wanted make sure I had
answers to your questions and a better understanding of the what might
be causing the Registry errors, and our security guru has been out with
the flu.

 

Yes, we have given recursive full rights to the HKey_Auth_Classes_Root
directory, as per your original advice. That has not eliminated the
problem, and we have serious concerns about giving that kind of access
on machines in the 12 open labs on campus where we provide WYNN and
other access software on machines available to more than 13,000 students
at UM.

 

I should mention at this point that we use Fine Reader to produce e-text
to our students, and I believe that that is the OCR engine WYNN 3.5
uses. Fine Reader has no problem converting PDFs to text, and these are
the same files that cause the registry errors in WYNN. The student
workers who do our e-text conversions using Fine Reader are generic
Windows Power Users, with none of the permissions modifications you have
said WYNN must have.(We do not have Fine Reader installed on the same
computers as WYNN, if that matters.) I wonder if WYNN can incorporate
Fine Reader's method of handling PDFs.

 

In our investigation of what may be causing WYNN's registry problems, I
need to correct the way I stated the kernel issue: My security guy says
the problems arise from operating in "Kernel Mode," not necessarily from
attempting to modify the kernel. He says this is a problem often seen in
software which requires an emulation of earlier Windows or DOS operating
environments, or 16-bit mode to run. These earlier environments (e.g.,
Windows 95, 98 and DOS) did not have the multi-user and/or multi-tasking
capabilities of Windows 2000 and XP, nor do they have the increasingly
stringent security of Windows 2000 and XP.  

 

The indicators that WYNN needs 16 bit mode (and consequently emulation
of earlier operating systems) to run can be found in the Windows Task
Manager "Processes" pane: When WYNN starts, Windows starts the
wowexec.exe, and winoldap.mod, both processes needed to emulate 16 bit
mode. The folks you work with at Microsoft can provide more info on
this, and if necessary, I can put your systems folks in touch with ours.

The emulation often causes security and other problems in a secure
Windows 2000 environment, though it may or may not be involved in the
Freedom Import Printer issues.

 

We spent a considerable amount of time locating and trying to
troubleshoot the WYNN's (and Open Book's) Freedom Import Printer, with
no success.

 

The bottom line for us is this: While we increasingly need a safe,
reliable tool to read PDF files aloud, and while WYNN seems capable of
doing this in home-user and insecure network environments, we have not
been able to make WYNN read PDFs--even after opening security (as you

recommended) to an extent that confidentiality of our student records
and the integrity of our network are compromised. If WYNN cannot process
PDFs in a secure environment we will need to find another method of
providing PDF access.

 

Could you provide contact information for other university network
administrators who have wrestled with this problem?

 

 

Nick Baker 
Assistive Technology Coordinator 
nick.baker at umontana.edu 
406-243-2234 (Voice/TTY) 
406-243-2663 (Voice only) 

Disabilty Services for Students 
The University of Montana 
EL 154 
32 Campus Drive 
Missoula, MT 59812 

  _____  

From: Kilcommons,Cath [mailto:cathk at cahs.colostate.edu] 
Sent: Thursday, October 14, 2004 11:12 AM
To: Baker, Nick; adtech-ps at lists.orst.edu; athen at lists.oregonstate.edu
Cc: Marks, Jim
Subject: RE: [athen] WYNN 3.5 PDF issues

 

We have had plenty of problems with PDFs and WYNN.  Students are often
jumping hoops to get them to save from WebCT and open in WYNN.
Unfortunately, for us the Freedom Import Printer is usually the answer
when all else fails.  Are you able to save the file to the local
computer?  Do you get the error when you open the PDF in WYNN, or when
you print from the PDF with the Freedom Import printer to WYNN?  

 

You could check the registry settings permissions... also the
permissions on the local drive where WYNN is installed.  Are you running
WYNN locally or is it a network install?

 

Regards,

Cath

--------

Cath Stager-Kilcommons

Assistive Technology Resource Center (ATRC)

Colorado State University

970-491-6258

cathk at cahs.colostate.edu

http://www.colostate.edu/Depts/ATRC/

 

  _____  

From: athen-bounces at lists.oregonstate.edu
[mailto:athen-bounces at lists.oregonstate.edu] On Behalf Of Baker, Nick
Sent: Thursday, October 14, 2004 10:35 AM
To: adtech-ps at lists.orst.edu; athen at lists.oregonstate.edu
Cc: Marks, Jim
Subject: [athen] WYNN 3.5 PDF issues

Has anyone on the list had problems (and hopefully solutions) using WYNN
to read PDFs in a secure network environment? The culprit is the Freedom
Import Printer, which fails with an "Error Reading Registry" message.
(Open Book uses the Freedom Scientific Printer with the same results.)

 

                        Nick

 

Nick Baker 
Assistive Technology Coordinator 
nick.baker at umontana.edu 
406-243-2234 (Voice/TTY) 
406-243-2663 (Voice only) 

Disabilty Services for Students 
The University of Montana 
EL 154 
32 Campus Drive 
Missoula, MT 59812 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman12.u.washington.edu/pipermail/athen-list/attachments/20041014/22eb4bcb/attachment.html>