Re: Ascii file generation questions
On 6/17/2003 6:37 AM, Illiano, Vincent wrote: Thanks for your response to my posting. I think a "mode" attribute to indicate whether to preserve text or format is a good idea. Either that, or add a '-ascii' attribute similar to '-txt' or 'pdf'... I realize this moves away from the 3 character extension (e.g., '-ps') but that may be better than adding a 'mode'... dunno. Unfortunately, I won't be able to help much, as my 'programming' skills are pretty much limited to hacking XSLT via the ol' trial and error method (emphasis on the error part...;-p). -- Clay Leeds - [EMAIL PROTECTED] Web Developer - Medata, Inc. - http://www.medata.com PGP Public Key: https://mail.medata.com/pgp/cleeds.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Ascii file generation questions
Hi Art, Thanks for your response to my posting. I think a "mode" attribute to indicate whether to preserve text or format is a good idea. Formatting issues can often be cleaned up by post-processing on the generated file. I'm already doing this to remove the extra new line feeds that I've had to add to solve the line overwriting problem. But when 2 lines are rendered onto each other - there is no way to fix that in a post-processing step. Do you or anyone else reading this thread have an idea how hard it would be to modify the TXTRenderer to preserve output text so that overwriting never occurs? Even though FOP's text output was never meant to be production quality, it's pretty darn good. I think a little tweaking to make it better would be a nice feature to have. I can volunteer to work on this. A little guidance would help me a lot. Who is most familiar with the TXTRenderer? Thanks, -V Vincent Illiano Senior Programmer/Analyst Duke University Heart Center > -- > From: [EMAIL PROTECTED]:[EMAIL PROTECTED] > Sent: Monday, June 16, 2003 2:37 PM > To: [EMAIL PROTECTED] > Subject: RE: Ascii file generation questions > > I do not know about the future of the TXTRenderer. But I do know a little > bit about it's past. > > The overwrite problem occurs because the TXTRenderer attempts to match the > positioning/layout of the PDF/PCL Renderers. Unfortunately plain text of > course does not have precise line positioning. Essentially the TXTRenderer > attempts to fit the layout onto a fixed character matrix. Quantization > effects cause the overwrite when a subsequent line ends up at the same > line > in the matrix as a previous line. I do not know that there is a perfect > solution to this problem. Perhaps extra lines could be added if an > overwrite > would occur, but then the layout would be compromised (perhaps this would > be > better than an overwrite). One of the original constraints when the > TXTRenderer was developed was that the text output fit within fixed page > sizes (fixed number of rows/columns). Depending on your application, this > may not be important. Perhaps a "mode" could be added to preserve text > (versus preserving layout). The only consolation I have had with regard to > the TXTRenderer is that I find its output superior to many commercial > applications' lame text output (IMHO). > > Art > > -Original Message- > From: Illiano, Vincent [mailto:[EMAIL PROTECTED] > Sent: Monday, June 16, 2003 2:28 PM > To: Illiano, Vincent > Cc: '[EMAIL PROTECTED]' > Subject: Ascii file generation questions > > > > Hi fellow Fop'ers, > > > > I've built a dynamic document generation system using FOP. I'm > > currently using version 0.20.4. The 2 supported output formats are > > PDF and ASCII text. I know that the ASCII renderer was never meant to > > be production quality. However, with some tweaking, I have been able > > to get out of it what I need. I'm including an example text output > > file that was generated by my system using FOP. > > > > The main problem that I have found with the text output generation is > > the line-overwriting problem. However, I have been able to fix this > > for the most part by adding extra space before the blocks where the > > overwriting occurs. For example: > > > > change > > Procedure Comment > > to > > Procedure Comment > > > > often fixes the overwriting problem that may occur in a particular > > paragraph of text. > > > > Is there someone on this list who can explain to me why the > > overwriting problem occurs and if it's something that could be fixed? > > I can volunteer to dig in and do it myself with just a little > > guidance. Also, is the text output feature planned in the redesign? > > I really hope so, because I think text is a valid output format. > > Again, I can volunteer to work on that feature if it's not already in > > the plan. > > > > Here is the example text file. Thanks, -Vincent > > > > <> > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Ascii file generation questions
Art (Welch?) wrote: > better than an overwrite). One of the original constraints when the > TXTRenderer was developed was that the text output fit within fixed page > sizes (fixed number of rows/columns). Depending on your application, this > may not be important. Perhaps a "mode" could be added to preserve text > (versus preserving layout). The only consolation I have had with regard to > the TXTRenderer is that I find its output superior to many commercial > applications' lame text output (IMHO). I have had this thought as well, basically to add a "rawtext" output option that would not be paginated. It would basically be another structured output option (similar to MIF and RTF), and would seem to be very easy to get working at a basic level (tables, etc. are extra). Except for line breaks (which should probably be optional), it really wouldn't add much value over using XSLT to spit out the content. Also, Vincent, I just added some content to the doc that was gleaned from an email that you wrote several months ago, that documents the optimal settings needed to avoid line overwrite, etc. Thanks for that useful information. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Ascii file generation questions
I do not know about the future of the TXTRenderer. But I do know a little bit about it's past. The overwrite problem occurs because the TXTRenderer attempts to match the positioning/layout of the PDF/PCL Renderers. Unfortunately plain text of course does not have precise line positioning. Essentially the TXTRenderer attempts to fit the layout onto a fixed character matrix. Quantization effects cause the overwrite when a subsequent line ends up at the same line in the matrix as a previous line. I do not know that there is a perfect solution to this problem. Perhaps extra lines could be added if an overwrite would occur, but then the layout would be compromised (perhaps this would be better than an overwrite). One of the original constraints when the TXTRenderer was developed was that the text output fit within fixed page sizes (fixed number of rows/columns). Depending on your application, this may not be important. Perhaps a "mode" could be added to preserve text (versus preserving layout). The only consolation I have had with regard to the TXTRenderer is that I find its output superior to many commercial applications' lame text output (IMHO). Art -Original Message- From: Illiano, Vincent [mailto:[EMAIL PROTECTED] Sent: Monday, June 16, 2003 2:28 PM To: Illiano, Vincent Cc: '[EMAIL PROTECTED]' Subject: Ascii file generation questions > Hi fellow Fop'ers, > > I've built a dynamic document generation system using FOP. I'm > currently using version 0.20.4. The 2 supported output formats are > PDF and ASCII text. I know that the ASCII renderer was never meant to > be production quality. However, with some tweaking, I have been able > to get out of it what I need. I'm including an example text output > file that was generated by my system using FOP. > > The main problem that I have found with the text output generation is > the line-overwriting problem. However, I have been able to fix this > for the most part by adding extra space before the blocks where the > overwriting occurs. For example: > > change > Procedure Comment > to > Procedure Comment > > often fixes the overwriting problem that may occur in a particular > paragraph of text. > > Is there someone on this list who can explain to me why the > overwriting problem occurs and if it's something that could be fixed? > I can volunteer to dig in and do it myself with just a little > guidance. Also, is the text output feature planned in the redesign? > I really hope so, because I think text is a valid output format. > Again, I can volunteer to work on that feature if it's not already in > the plan. > > Here is the example text file. Thanks, -Vincent > > <> > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Ascii file generation questions
> Hi fellow Fop'ers,
>
> I've built a dynamic document generation system using FOP. I'm currently
> using version 0.20.4. The 2 supported output formats are PDF and ASCII
> text. I know that the ASCII renderer was never meant to be production
> quality. However, with some tweaking, I have been able to get out of it
> what I need. I'm including an example text output file that was generated
> by my system using FOP.
>
> The main problem that I have found with the text output generation is the
> line-overwriting problem. However, I have been able to fix this for the
> most part by adding extra space before the blocks where the overwriting
> occurs. For example:
>
> change
> Procedure Comment
> to
> Procedure Comment
>
> often fixes the overwriting problem that may occur in a particular
> paragraph of text.
>
> Is there someone on this list who can explain to me why the overwriting
> problem occurs and if it's something that could be fixed? I can volunteer
> to dig in and do it myself with just a little guidance. Also, is the text
> output feature planned in the redesign? I really hope so, because I think
> text is a valid output format. Again, I can volunteer to work on that
> feature if it's not already in the plan.
>
> Here is the example text file. Thanks, -Vincent
>
> <>
>
DISCH2
DMCRES
226050-5739286
701
CardioThoracic Surgery
CardioThoracic Surgery
1997072100
20030616140208
CTSURG
P
275900
Landolfo
Kevin
P
Z9
TESTPATIENT
MARY
TEST SR
023433
TX
1
Complete Report
Complete Report
The report in the patient record was created using another software database
system. This electronic report represents the content but not the format
of the original. For patient care use, please refer to the chart record.
DUMC
THORACIC SURGERY SERVICE
DURHAM, NC
Name: TESTPATIENT, Sr, RN, MARY TEST PATIENT
MRN: Z9 DOB: 08/04/1935
Referring provider: Cynthia Steinem, MD; Colvin, O Michael, MD; L J Pace, MD
Referring Cardiologist: Victor S Behar, MD
Surgeon: Landolfo, Kevin P, MD
Procedure Date: 07/21/1997
Operative Note - Cardiac Surgery
MARY TEST PATIENT TESTPATIENT, Sr, RN is a 61 year old Hispanic female from
Hamilton, who was referred by Victor S Behar, MD from Durham, NC, L J Pace, MD
from Princeton, WV, Cynthia Steinem, MD from Raleigh, NC, Colvin, O Michael,
MD from Durham, NC.
Diagnosis - Non-Coronary
Stenosis - aortic
Procedures
CABG x 1
Mitral valve replacement, Aortic valve replacement
Operative Personnel
Surgeon: Kevin P Landolfo, MD
Anesthesiologist: Bruce J Leone, MD
Perfusionist: Curtis L King
Assisting MD: Joseph M Forbess, MD
Physician's Assistant: James T Marshall, PA-C
Clinical History
Indication(s) for Operation - Coronary: Failed angioplasty, Congestive
heart failure
Valve Disease Etiology: Calcific
NYHA Class: II - Sx with moderate exertion
Left Ventricular Function: Normal (EF>50%)
Coronary Artery Disease Status: No significant CAD indicated
Operative status: Emergency - first available room with hemodynamic
instability
Closure Techniques
Staples
Operative Procedure
Patient location prior to procedure: Transferred from another facility
Anesthetic: No Medications Indicated
Incision Type: Median (Full) sternotomy
Bypass graft(s) obtained: Left mammary artery - Endoscopic, Left radial
artery - Open (incision), Homograft - Open (incision)
Left ventricular status:
Single scar sites - Antero-apical
Multiple scars - Antero-apical
LV aneurysm - Posterior, Antero-apical
Previous repair
Hypertrophy
Dilation
Ischemia
Cannulation Sites: Vena cava
Chambers opened: Aorta, Pulmonary artery, Right atrium
Hemodynamic difficulties pre-procedure: Hypotension
Number of proximal anastomoses prior to cross clamp: 2
Number of proximal anastomoses during cross clamp: 3
Minimum myocardial temperature: 37.10 (Degrees C.)
Minimum inflow temperature during cross-clamp: 38.00 (Degrees C.)
Minimum nasopharyngeal temperature: 34.00 (Degrees C.)
Cardioplegia infusion: Other
Cardioplegia administration: Antegrade - 1400 ml
Topical cooling: Slush
Aortic Occlusion Method
Not used
VALVE MATRIX
ValveDescription Repair Previous valve excised
--- --- --
1 Aortic Stenotic, Calcified Native
ValveValve inserted Valve Left Size (mm) Suture
---
1 Aortic St. Jude 19.0 2/0
ValveTechnique Serial No.Model No.
- - -
1 Aortic Subannular pledgets60344649
GRAFT MATRIX
Coronary Graft Target Artery
