As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only.
Join the TIBCO Community TIBCO Community is a collaborative space for users to share knowledge and support one another in making the best use of TIBCO products and services. There are several TIBCO WebFOCUS resources in the community.
From the Home page, select Predict: WebFOCUS to view articles, questions, and trending articles.
Select Products from the top navigation bar, scroll, and then select the TIBCO WebFOCUS product page to view product overview, articles, and discussions.
Request access to the private WebFOCUS User Group (login required) to network with fellow members.
Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community.
I have a WF report that, among other things, prints out text in PDF format. My problem is that the carriage returns are missing in the final product and all of the nicely formatted paragraphs are all run together making the text rather hard to read.
The text is entered via a browser into a multi-line text area and stored in SQL in a text data type. We are using WebFOCUS 5.3. How do I get WebFOCUS to honor the hard carriage returns stored in the database?This message has been edited. Last edited by: Kerry,
You cannot open a PDF file in a text editor and expect to see carriage returns/line feeds. A PDF file is not a text file.
The carriage returns/line feeds in your SQL table data will have to be detected and acted upon by the WebFOCUS program. I would suggest splitting the text-area into separate SQL data rows at each entered carriage return/line feed.
I imagine the CRLF's are buried in the middle of your data - not always at the end of the data. Does that mean each data row may contain more than one paragraph of text? Does that also mean that more than one data row may make up one paragraph of text?
It would take a bit of program code to separate the paragraphs but I don't think it's impossible.
Interesting problem here. I tried this out. It turns out that FOCUS *does* pass LF/CR to the PDF file. If you open up the PDF file w/ Wordpad (or some other editor that recognizes LF/CR) you can see this. It is PDF itself which does not recognize LF/CR. PFD files have a different mechanism for storing/recognizing new lines (ummm, I guess that's why it's called PDF format).
Anyway, there should be a way to split up your text using the GETTOK function. Assuming that you text is not in a database CLOB, you can do this in a DEFINE:
This might be rather late to mention given that the earlier entries came in late 2004, but in WF 7.1.4 you may add the stylesheet setting
TYPE=REPORT,LINEBREAK='CRLF',$
where CRLF indicates carriage return/line feed. The linebreak might be CR or LF or some alternative based on what is embedded in the text.
The good news is that this setting works great for PDF. The difficult news is that it is not accepted in Active Reports (AHTML). We have a setting of WRAP=3.00 for a column that is 1154AV with CRLF symbols and it rolls out like a carpet and does not wrap.
So if anybody can help us with this AHTML issue we would be highly indebted to you!
New_Text6/A33 = CTRAN(33, New_Text5, 059, 013, New_Text6); -- Changes a semicolon (059) in the text into a CR (013) . . . TYPE=REPORT,LINEBREAK='CR',$
I added this to the end since the current help files show the answer in EBCDIC. This worked for me for a PDF report, though fair warning -- it creates a second line from a style sheet point of view. A simple in html output strings creates a second line without changing my background coloring.
J.
Posts: 1012 | Location: At the Mast | Registered: May 17, 2007