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 fo:blockProcedure Comment/fo:block to fo:block space-before=10.5ptProcedure Comment/fo:block 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 vreport.txt - 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
fo:blockProcedure Comment/fo:block
to
fo:block space-before=10.5ptProcedure Comment/fo:block
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
vreport.txt
BOF
SendAppDISCH2
ReceivAppDMCRES
PNEvntNo226050-5739286
EvntCod701
EvntLngNmCardioThoracic Surgery
EvntShtNmCardioThoracic Surgery
EvntDT1997072100
EvntChgDT20030616140208
HCtrSecIDCTSURG
EvntRsltStP
PriIntCod275900
PriIntLNmLandolfo
PriIntFNmKevin
PriIntMNmP
PMRNZ9
PLNameTESTPATIENT
PFNameMARY
PMNameTEST SR
PAcctNo023433
ValueTypeTX
ObsrvIDCod1
ObsrvLngNmComplete Report
ObsrvShtNmComplete Report
BRPT
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 (EF50%)
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
Valve
ASCII text output and pagination
Hi all, I'm using FOP to generate PDF and corresponding ASCII text output files. I'm using FOP to generate the corresponding ASCII output instead of just straight XSL because the reports I'm creating contain many tables with varying widths and columns. I also didn't want to have to worry about line breaking. The ASCII text output is actually working quite nicely. Figuring out what font-family (Courier), font-size (7.3pt), and line-height (10.5pt) to use solved the problems I was having with missing spaces and sequential lines in the output overlaying one another. There is still one problem I need to solve - pagination. The text output files that I'm creating do not need pagination, since they are just one long virtual page. But FOP is inserting page breaks at the page boundries. Is there a way to tell FOP not to insert page breaks in text mode? I know I can solve the problem by creating a simple-page-master with an arbitrarily long page-height, and then do some post-processing on the generated output file. But I thought I'd see if there's a more elegant solution. If FOP cannot currently surpress page breaks in text mode, how hard would it be for me to add this functionality myself? Can anybody familiar with the ASCII renderer point me where to look? Thanks! -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: ASCII text output and pagination
Hi Jeremias, Thanks for the quick response. I am willing to add media-usage support to FOP. I have a couple of questions on this, though. Given that I need this functionality now, if I add it to the redesigned FOP branch, when will I be able to use it? When will the first release of the redesiged FOP be available? If I decide to put the support in the maintainance branch because I need it now, would it be difficult to port it later to the new FOP? I guess we should also ask the question if there are other FOP users out there who would like to see ASCII support in the redesigned FOP. I, personally, have found it very useful! One more thing. I am not familiar with the layout engines. How difficult will it be to teach it not to make page breaks and to increase the page length dynamically? Thanks again for your response, -Vincent -- From: Jeremias Maerki[SMTP:[EMAIL PROTECTED] Reply To: [EMAIL PROTECTED] Sent: Wednesday, March 05, 2003 10:28 AM To: [EMAIL PROTECTED] Subject: Re: ASCII text output and pagination The correct thing to do whould be to use media-usage=bounded-in-one-dimension on fo:root. The problem is that this isn't implemented in FOP, yet. And it's not only a matter of changing the ASCII renderer, I'm afraid. You would have to teach the layout engine not to make any page breaks and to increase the page length as necessary. If you decide to try fixing that I would recommend you to work with us on the redesign to implement this feature because the maintenance branch (from which 0.20.5 originates) will soon be discontinued. The other problem is that the ASCII renderer hasn't been brought back in the redesign. So it would involve helping us with that one, too. On 05.03.2003 16:14:54 Illiano, Vincent wrote: Hi all, I'm using FOP to generate PDF and corresponding ASCII text output files. I'm using FOP to generate the corresponding ASCII output instead of just straight XSL because the reports I'm creating contain many tables with varying widths and columns. I also didn't want to have to worry about line breaking. The ASCII text output is actually working quite nicely. Figuring out what font-family (Courier), font-size (7.3pt), and line-height (10.5pt) to use solved the problems I was having with missing spaces and sequential lines in the output overlaying one another. There is still one problem I need to solve - pagination. The text output files that I'm creating do not need pagination, since they are just one long virtual page. But FOP is inserting page breaks at the page boundries. Is there a way to tell FOP not to insert page breaks in text mode? I know I can solve the problem by creating a simple-page-master with an arbitrarily long page-height, and then do some post-processing on the generated output file. But I thought I'd see if there's a more elegant solution. If FOP cannot currently surpress page breaks in text mode, how hard would it be for me to add this functionality myself? Can anybody familiar with the ASCII renderer point me where to look? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: ASCII text output and pagination
Ok, I think I'd like to pursue 2 possibilities. If someone out there listening in on this discussion can give me a pointer to the ASCII layout engine and a pointer on how to teach it to increment to page length, then I will take a shot at implementing bounding-in-one-dimension in the maintainance branch at least. If some of the more experienced FOP developers agree with me that ASCII rendered output support would be a nice feature for the redesigned FOP, and it's feasible, then I'd like to contribute. Thoughts, suggestions? Thanks, -Vincent -- From: Jeremias Maerki[SMTP:[EMAIL PROTECTED] Reply To: [EMAIL PROTECTED] Sent: Wednesday, March 05, 2003 11:07 AM To: [EMAIL PROTECTED] Subject: Re: ASCII text output and pagination On 05.03.2003 16:53:15 Illiano, Vincent wrote: Thanks for the quick response. I am willing to add media-usage support to FOP. I have a couple of questions on this, though. Given that I need this functionality now, if I add it to the redesigned FOP branch, when will I be able to use it? If the functionality available in the redesign already fits your needs (check that please) you can start using it immediately. Just download it from CVS as indicated on our website. When will the first release of the redesiged FOP be available? Unknown. There's still a lot to do. But please do have a look at the redesign. If I decide to put the support in the maintainance branch because I need it now, would it be difficult to port it later to the new FOP? I think, yes. The reason is that the layout engine is completely different. The renderers are still pretty similar, but your functionality need to be implemented in the layout engine. I guess we should also ask the question if there are other FOP users out there who would like to see ASCII support in the redesigned FOP. I, personally, have found it very useful! One more thing. I am not familiar with the layout engines. How difficult will it be to teach it not to make page breaks and to increase the page length dynamically? Hmm, I can't answer that off-hand. I'm the peripheral guy here, sort of, read: specialist for everything but layout. :-) I hope Keiron can answer that. If you need your functionality real quick, I suggest you go the post-processing way. But it would certainly be cool to have new people jump in and help. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
