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.
Hi, We are using Special Symbols(Double Dagger ‡) in our reports and it s not getting displayed when the output format is EXL2K.We already changed the Codepage to 137 on the Reporting server console but still unable to display it. the report is working fine for both HTML and PDF Outputs.
TABLE FILE CAR PRINT RETAIL_COST COMPUTE FLD1/A1 = '?'; COMPUTE FLD2/A1 = HEXBYT(135,FLD2); COMPUTE VAL1/A1 = ';';NOPRINT COMPUTE FLD3/A1 = CTRAN(1, VAL1, 59, 135, FLD3); ON TABLE SET ONLINE-FMT EXL2K ENDThis message has been edited. Last edited by: Kerry,
I don't know if this will help, or if you've already done this, but set the NLS WebFOCUS code page to 137 in both the WebFOCUS Admin Console and the WebFOCUS Server Console.
Francis
Give me code, or give me retirement. In FOCUS since 1991
Production: WF 7.7.05M, Dev Studio, BID, MRE, WebSphere, DB2 / Test: WF 8.1.05M, App Studio, BI Portal, Report Caster, jQuery, HighCharts, Apache Tomcat, MS SQL Server
i tried setting the codepage to 137 but still unable to display the double dagger symbol.I am able to generate the report but the symbol is displayed with an unknown character.
i tried setting the codepage to 137 but still unable to display the double dagger symbol
Same here! The symbols display correctly in HTML and PDF but not in Excel.
After running ? LANG as Francis suggested, this is what I get:
Language 001/AMENGLISH ( ,en)
Code Page 137
Client Code Page 137
Dollar 24($)
Lowcase alphabet YES
Decimal notation OFF(.)
Currency symbol $
Date/Time format EDA
NLS sort YES
NLS upcase/lowcase YES
NLS Control Characters OFF
DBCS Flag OFF(SBCS)
Both Server and Client code pages are set to 137, unlike Francis' environment that has 437 in the Client side. Could that be the reason why it is not working for me?
I changed the client code page on AIX to 137 and now I see double-daggers in HTML and PDF for FLD2 and FLD3, but not for FLD1. EXL2K does not get any double-daggers.
Francis
Give me code, or give me retirement. In FOCUS since 1991
Production: WF 7.7.05M, Dev Studio, BID, MRE, WebSphere, DB2 / Test: WF 8.1.05M, App Studio, BI Portal, Report Caster, jQuery, HighCharts, Apache Tomcat, MS SQL Server
There is a way to make it work in Excel via HTMLFORMTYPE but what this does is actually forcing the browser to open the HTML file using the Excel plug-in (helper application) but internally it is still an HTML document!.
Although the double-dagger symbols gets displayed, this may not be something you want if you need to use reporting features only available to actual Excel 2000+ files such as: EXL2K PIVOT, EXL2K FORMULA, EXL2K BYTOC ....
If you can live without any of those, then give this one a try:
SET HTMLFORMTYPE = XLS
TABLE FILE CAR
PRINT RETAIL_COST
COMPUTE FLD1/A1 = '?';
COMPUTE FLD2/A1 = HEXBYT(135,FLD2);
COMPUTE VAL1/A1 = ';'; NOPRINT
COMPUTE FLD3/A1 = CTRAN(1, VAL1, 59, 135, FLD3);
ON TABLE HOLD AS HOUT FORMAT HTMTABLE
END
-RUN
-HTMLFORM BEGIN
<html><body>!IBI.FIL.HOUT;</body></html>
-HTMLFORM END
After changing Server and Client code pages to 437, I still don't get it to work correctly.
? LANG
NATIONAL LANGUAGE INFORMATION
Language 001/AMENGLISH ( ,en)
Code Page 437
Client Code Page 437
Dollar 24($)
Lowcase alphabet YES
Decimal notation OFF(.)
Currency symbol $
Date/Time format EDA
NLS sort YES
NLS upcase/lowcase YES
NLS Control Characters OFF
DBCS Flag OFF(SBCS)
Excel is displaying a French c cédille (ç) instead of the double-dagger symbol.
In code page 437, it works fine. EXCEL also I got the exact symbol.
Oh, I've got it now!
It's not that it works in Excel but rather than it works with EXCEL output format. However, it doesn't with EXL2K.
For some reason, whenever I think of Excel reports my mind switches to EXL2K right away.
There are many interesting features available only in EXL2K format (such as report stylesheets for instance) which aren't in EXCEL, so this would be another trade-off.
In fact, when using EXCEL output format it works fine even when using the 137 Western Europe (Latin-1) code page we regularly use to support both English and French versions of our reports.
TABLE FILE CAR
PRINT RETAIL_COST
COMPUTE FLD1/A1 = '?';
COMPUTE FLD2/A1 = HEXBYT(135,FLD2);
COMPUTE VAL1/A1 = ';'; NOPRINT
COMPUTE FLD3/A1 = CTRAN(1, VAL1, 59, 135, FLD3);
ON TABLE PCHOLD FORMAT EXCEL
END
Sadly, styling is not supported in that format which would be a significant drawback for some environments (like the one I use).
Would there be a way (other than using HTMLFORMTYPE) to support both styling and the double-dagger symbol (and others)?
NATIONAL LANGUAGE INFORMATION
Language 001/AMENGLISH ( ,en)
Code Page 437
Client Code Page 437
Dollar 24($)
Lowcase alphabet YES
Decimal notation OFF(.)
Currency symbol $
Date/Time format EDA
NLS sort NO
NLS upcase/lowcase NO
NLS Control Characters OFF
DBCS Flag OFF(SBCS)
Weird. It works for me in HTML, DHTML, EXL2K, EXCEL, and PDF.
WebFOCUS 7.7.05
Posts: 1213 | Location: Seattle, Washington - USA | Registered: October 22, 2007
I don't know whether or not that's related to the issue under discussion. I need to research how to change those particular settings in my test environment to see what happens ...
To make it even more interesting ... running the code in WF 5.3.4 gives me the double-dagger symbol in EXL2K ... running it in 7.6.11 with the same code pages still gives me a c-cédille
code page 137 - Information Builders proprietary code page, which handles all major North American, South American, and Western European languages (except Greek) for Windows and UNIX. Code page 137 is functionally equivalent to the Microsoft Windows 1252 and UNIX ISO 8859-1 code pages.
quote:
ANSI - Acronym for American National Standards Institute. Refers to the IBM PC-compatible Microsoft Windows 1252 Latin-1 code page.
quote:
ISO - Acronym for the French name of the International Organization for Standardization. It sometimes refers to the ISO-8859-x family of UNIX code pages, and specifically the ISO-8859-1 Latin-1 code page, which has the same layout as the Windows 1252 code page and Information Builders proprietary code page 137.
Francis
Give me code, or give me retirement. In FOCUS since 1991
Production: WF 7.7.05M, Dev Studio, BID, MRE, WebSphere, DB2 / Test: WF 8.1.05M, App Studio, BI Portal, Report Caster, jQuery, HighCharts, Apache Tomcat, MS SQL Server
Code page 137 is functionally equivalent to the Microsoft Windows 1252 and UNIX ISO 8859-1 code pages.
Hmmm, based on the documentation it seems to me that by using Code Page 137 we should then be well covered when dealing with special characters (other than Greek). I still don't understand why I keep getting the wrong double-dagger representation in EXL2K
I'll do as wf_devloper says and will switch to 1252 instead but it doesn't make much sense if in theory code 137 is equivalent to MS 1252
I had to change the code page for both the Client and reporting servers to 65001 - Unicode (UTF-8) on a multi-tier environment where the reporting server is on UNIX...
Francis
Give me code, or give me retirement. In FOCUS since 1991
Production: WF 7.7.05M, Dev Studio, BID, MRE, WebSphere, DB2 / Test: WF 8.1.05M, App Studio, BI Portal, Report Caster, jQuery, HighCharts, Apache Tomcat, MS SQL Server
According to the DB guy, the database is set to 1252. 1252 is equivalent to 137 and neither works with this database so I think he's wrong. It must be Unicode.
Francis
Give me code, or give me retirement. In FOCUS since 1991
Production: WF 7.7.05M, Dev Studio, BID, MRE, WebSphere, DB2 / Test: WF 8.1.05M, App Studio, BI Portal, Report Caster, jQuery, HighCharts, Apache Tomcat, MS SQL Server