Bug 505223

Summary: Can't convert a .ps file to .ascii file
Product: Red Hat Enterprise Linux 5 Reporter: Qunfang Zhang <qzhang>
Component: ghostscriptAssignee: Tim Waugh <twaugh>
Status: CLOSED WORKSFORME QA Contact: QE Internationalization Bugs <qe-i18n-bugs>
Severity: medium Docs Contact:
Priority: low    
Version: 5.3CC: lihuang, pknirsch
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-14 08:36:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
A ps format file none

Description Qunfang Zhang 2009-06-11 04:50:17 UTC
Description of problem:
Can't create the file.ascii. Display some error message said: /rangecheck in -- peekstring
.......
ESP Ghostscript 815.02:Unrecoverable error,exit code 1.

Version-Release number of selected component (if applicable):
ghostscript-8.15.2-9.9.el5
(Release-Archs Covered: rhel5client-- i386)


How reproducible:
Always

Steps to Reproduce:
1. Get the .ps file.
2. Issue command 'ps2ascii  file.ps '  under gnome-terminal.

  
Actual results:
The file.ascii file isn't created successfully.

Expected results:
The file.ascii file is created successfully.

Additional info:
The .ascii file can be created successfully on the rhel5client-x86-64

Comment 1 Qunfang Zhang 2009-06-30 09:58:41 UTC
Created attachment 349932 [details]
A ps format file

Comment 2 Qunfang Zhang 2009-06-30 10:00:30 UTC
I have uploaded a ps format attachment that can help reproduce this issue.

Comment 3 Phil Knirsch 2009-10-12 11:59:27 UTC
I've tried this on several machines with RHEL-5.3 and RHEL-5.4, both 32 and 64bit and can't reproduce the problem.

Could you provide a sosreport please?

Thanks & regards, Phil

Comment 4 Qunfang Zhang 2009-10-13 02:30:50 UTC
Hi, Phil
I tried this with the attachment in BZ on the stable machines because the original environment did not exist, but I cannot reproduce it too. The ascii file was created and displayed in the terminal. Below is my result. Is it correct?  


.qa.[root@i386-5c-m2 ~]# ps2ascii download.ps 


Babar Online Meeting, February 3 1999 David Brown, LBL

Online File Download System Cosmic run configuration relied on NFS file access

Hard-coded configuration `key' valuesPrivate files, file formats

BaBar online has a design for data download

Objectivity config conditions

DownloadServer proxy proxy

proxy proxy

ReverseDataflow persistentobjects TaggedContainers End

Users requests

We aren't ready to deploy the real system today

RDF is not readyPersistent form of config data, Proxies not yet written by subsystems

We need (some of) this functionality to run in April

Documented, dynamic, data-driven configuration download

requests

type,name,(key,time),

odfdAdr

Babar Online Meeting, February 3 1999 David Brown, LBL

The Interim Download System Uses NFS file access as a `transport' mechanism

Can reuse existing data files (if written in XTC format)NFS file access is working acceptably (new server,single NFS mount)

Provides true configuration key management

Key values are uniquely associated with config dataProvides access to conditions DB data (calibration)

Provides realistic coding interfaces

Real Server interface implementation

Can be used as-is underneath rdf once that's deployedReal Dataflow interfaces for config and calibration data

will need some modification when rdf is deployedExploits the real Config DB browser/editor tools

Allows integration of DF and DC configure transition by RCCan be updated adiabatically as data is entered in Config DB


Babar Online Meeting, February 3 1999 David Brown, LBL

How It Works Data files must be placed on the server

/nfs/bbr-srv02/dataflow/rdf/Xxx/YourDirectory/YourFile.xtcSubsystem experts have write access to Xxx

Files MUST have odfContainerIO::writeXTC() format

Existing CycleTC files are probably the wrong format (odfContainerIO::writeArena() format)7.11.1 OdfContainerTools contains an executable for converting file formats

File names are completely arbitraryConfig files must be registered in the config DB (stay for Yury)

Associates a file with an config transition env valueOnce registered, files may not be modified (checksum validation) Conditions data must also be registeredAt run-time, an index of files is created from the DB(Yury)

Accessors (next slide) will find the right file given the request

Babar Online Meeting, February 3 1999 David Brown, LBL

User Interface Defined in RdfOdf package

Also need RdfCommon, RdfTools, + `calibration' librariesRDF Libraries are in /dataflow/rdflib

Data is proxied by an instance of RdfLoader

RdfLoader owns/manages the data it fetchesCan (should) be data members of odfAction subclass

RdfConfigLoader<YourData> subclass

Fully implementedInstantiate with the config data name

Fetch data with YourData* getXTC(odfTransition)CalTCLoader<YourCC> subclass

Fully implementedInstantiate with CalType name Fetch data with CalTC<YourCC>* getCalTC(odfTransition)Currently, only supports data fetching on `configure'

A fix for other transitions is upcoming


Babar Online Meeting, February 3 1999 David Brown, LBL

Core Calibration Changes CalConfigAction now uses RdfLoader for CalCycleTCs

Default name "CalCycles" can (should) be overridden on constructionCalConfigAction::globalConfig and 

CalBeginAction::cycleConfig prototype has changed

was (odfEnv,odfFSM); now (odfTransition,odfFSM)Need transition to pass to RdfLoader

checks transition valuegets time for conditions DB access CalCycleManager (DF Proxy) uses RdfLoaderDirc example (fully tested) in recently announced tag

DrcCalConfig uses RdfConfigLoader to fetch front-end configuration data

Babar Online Meeting, February 3 1999 David Brown, LBL

Migration and Deployment All the dual-use + DB code was announced for 7.11.1An online release will be built on this `this weekend'

George Zioulas will install an IR2 Objectivity federation based on 7.11.1 schema Subsystems need to migrate their CalBeginActionsSubsystems need to migrate their data files Subsystems need to register their filesRC must migrate

Top keys (+ aliases?) need to be defined for all run types

Comment 5 Phil Knirsch 2009-10-13 13:01:39 UTC
Looks like mine and resembles as good as it can the original postscript document.

Would you agree we can close this bug then? Feel free to reopen it if you stumble across the bug again in the future.

Thanks & regards, Phil

Comment 6 Qunfang Zhang 2009-10-14 02:05:50 UTC
Yes, as the bug cannot be reproduced and the function works well, I agree with you to close this bug. It can be reopened if we reproduce it again.

Thanks :)