Hi all,

I have just found out that all CSS classes generated by WebFOCUS (7.7.03 HF6) are given the "pt" size unit. Especially a

BORDER=LIGHT,

attribute results in something like

 .x1 { border-top: 1.00[B]pt[/B] SOLID #000000; ... } 

. AFAIK the default unit for borders on an HTML page (screen optimized,

 SET PRINT=ONLINE 

) is px not pt.
While this might not look as a problem per-se, I have now seen, that this results in an interpolated ~ 1.333 px wide border on Internet Explorer 10 (when using it to Standard Mode, not Quirks).

Btw.: Windows has a ratio pt -> px of = 96/72 ~= 1.333 in default settings while it should be 72/72 = 1 under unix / linux.

Is there any way to tell WebFOCUS to generate styles with borders in (std.) unit = n px (Pixels) other than re-writing all CSS classes yourself and using

 CLASS=myClass, 

? It would be really tedious and hard to maintain if we would have to do so specially for HTML (not using BORDER... but own CSS), but using default WF Styling for all other output formats.

Thanks in advance for your help

Cheers Linne

This message has been edited. Last edited by: linnex,

Linne,

I've found it impossible to create pixel perfect HTML reports. You would think that by now we would be able to specify pixel sizes in the WebFOCUS style-sheet, but it's not possible.

At our site, we use UNIT=PTS in the WebFOCUS style-sheet because it's the smallest unit we can specify. Then, for borders, we use BORDER-TOP=0.5, which translates to this CSS: border-top: 0.50pt.

We cannot get any more accurate than this.

For B.I. Dashboards, I'm almost ready to give up on HTML reports and rely on creating my own HTML in an ALPHA hold file.

Hi Francis,

thanks for your response. I had the feeling (or fear) that the answer would be much like this.

BORDER-TOP=0.5, helps already - though of course not very nice and not at all pixel perfect .

Nevertheless it still means that we have to look into and change all table reports using BORDER=LIGHT ... oh no

Creating an ALPHA with my own HTML code - I am not ready to give up all "comfort" yet and do all by myself. but I am doing that already for generating my own SVG graphs - much more powerful and customizable than IBIs engine on 7.7.

Thanks again and cheers
Linne

quote:

This message has been edited. Last edited by: Kathryn Henning, March 14, 2014 01:59 PM

Hi Kathryn,

why have you changed my post to "SOLVED". Francis also said, that it is virtually impossible to create pixel perfect HTML reports with WebFOCUS out-of-the-box.
It really seems that the WF generated HTML reports will always generate borders with a CSS setting "pt" instead of "px". Only a rough workaround has been sketched here.
The problem is hardly solved with WF when community members resignate and say that they now tend to create HTML reports on their own using ALPHA rather than using WFs methods!

IMHO it would be better to forward this info to IBI & WebFOCUS production unit than to ignore this!

Thanks and regards
Linne

Linne, you can remove the "[SOLVED]" text by editing your initial post.

Hi Linne,

I marked this post SOLVED based on your comments of how you accomplished this. If you would like to see a change in how pixel perfect HTML reports are generated, please open a New Feature Request case on InfoResponse Online. You can reference this topic in the comments for some background.

Cheers!

Kathryn

Kathryn, this is definitely not "solved". We don't understand why 'pixel' is not a unit we can use to create reports for web browsers.

Cheers,

Hi Francis,

I removed the SOLVED keyword after replying to Linne and further understanding the issue behind this topic.

I researched the existing New Feature Requests to see if this one has been submitted, but it hasn't. New Feature Requests do take some time to be implemented if selected, and since this sounds like a feature that you're also interested in, please also open a case on InfoResponse Online. This allows us to gauge interest is a particular feature.

Thanks and regards,

Kathryn

Hi Kathryn, hi Francis,

thanks for your responses.
Following your suggestion I have submitted an NFR (Case 10783535) to InfoResponse.

Thanks, Francis, for the tip concerning the Edit bt. I have updated the post to "NFR Opened".

Cheers
Linne

Thanks Linne!