Support for Drop down list
Hi Experts, Does Apache FOP support drop down menus or expandable links. I am looking for something like, if I click, say on a button, it expands and gives me a list of items under it. If I click again the list disappears. Is it supported in Apache FOP 0.95? Thanks in advance. Regards, -- Suvrat Hiran
DO NOT REPLY [Bug 52625] border-left / border-right renders incorrectly
https://issues.apache.org/bugzilla/show_bug.cgi?id=52625 --- Comment #4 from Santanu Dutta 2012-02-09 06:59:07 UTC --- I do not agree with the fact that this is subject to device capabilities instead it is because of the FOP itself. I could consider that in the testcase I've used «0.1pt», and that might be too narrow width for printers, but that could be changed to 0.5pt/1pt/1px, but still the problem persists(only with FOP generated PDF, not with XEP output). I also do not agree that both PDF files(FOP & XEP output), are viewed same at greater zooming(200% or more). But I somhow agree that, it could be said that «border-width problem is inversely proportional to the zooming factor, more the zooming less is the problem». Though same border-width value have been used throughout the "test.fo" file but, on viewers (Acrobat v7.0, v9.0 & v10.0, Foxit Reader, Nuance PDF) the differences are well seen. Conclusion: By changing border-width(lesser or much), this issue is not going to fix. There might be situations where A3 size paper could be printed in A4 paper with lesser zooming. In this case this output is really very bad(as the case of mine). Moreover, I've also noticed that, if the border-style is set to «inset/outset» the left and right borders seems good, but goes wrong if the border-style has been set to «solid». I am trying to figure-out any patch(es) that could fix the issue, but by then my humble request to developers, testers and users is that kindly look into this issue and suggest if you have also faced this kind of problem. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 52625] border-left / border-right renders incorrectly
https://issues.apache.org/bugzilla/show_bug.cgi?id=52625 Santanu Dutta changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: change to PNGImageReader in jdk1.6_14 impacts performance with some PNG images
Ognjen, Thanks for pointing that out. Someone had already called my attention to that thread, which is indeed the same issue I faced. Jeremias suggested (private communication) a different approached, which I tried, and consists in having an "alternative" optimizedWriteTo() function to deal just with BGR images. It is very much like the original one, except that the B and R bytes are permuted (so that we get RGB) before performing the write call. That led to very good performance gains when the CPU is underutilized, although the gains are less impressive when the CPU saturates. Luis On 2/7/12 11:40 PM, Ognjen Blagojevic wrote: Luis, On 6.2.2012 13:11, Luis Bernardo wrote: follows the writeRGBTo() path instead of the previous optimizedWriteTo() path. The end result is a 40% performance impact for the PNG file I have been testing with when going from jdk1.6_13 to a more recent one, like jdk1.6_30. Any ideas on how to recover the previous performance (i.e., use the optimizedWriteTo() path)? Take a look at this thread: http://www.mail-archive.com/fop-dev@xmlgraphics.apache.org/msg13492.html And this issue: https://issues.apache.org/bugzilla/show_bug.cgi?id=51149 I was able to recover performance by removing color profile information from PNG. -Ognjen
DO NOT REPLY [Bug 52625] border-left / border-right renders incorrectly
https://issues.apache.org/bugzilla/show_bug.cgi?id=52625 Pascal Sancho changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #3 from Pascal Sancho 2012-02-08 14:52:34 UTC --- test case gives 0.1pt width borders, witch is quite below what either screen or printer can display: 0.1pt gives 1/720" current screen res: 1/96" current laser printers res: 1/300 to 1/600", witch is larger than your border width. Result: the display (either on screen or printer) depends on how viewer handle below-device-res elements (rounding values, anti-aliasing mode, etc.) When zooming in to 200%, both Xep and Fop give expected results (on screen, with Adobe viewer 9), and on my printer, both Xep and Fop give missing borders, mainly due to very small width. So, the test case is subject to device capabilities, and Fop design is not (IMHO) in cause. That said, feel free to reopen if you can arg that this issue is not device dependent. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [VOTE] merge Temp_ImproveAccessibility to trunk
+1 from me. Peter, you might want to have a VOTE recorded too! ;-) "My religion is simple. My religion is kindness." - HH The Dalai Lama of Tibet On Feb 1, 2012, at 7:40 AM, Peter Hancock wrote: > Hi All, > > Vincent and I have recently been working to improve the generation of > tagged PDF and we now propose merging the branch > Temp_ImproveAccessibility into trunk. > > The objectives and an implementation plan was summarised by Vincent in > [1] and development has remained fairly faithful to that proposal. > > A core objective of this work was to remove the XSLT pre-process stage > and instead build the structure tree from FONode creation events and > this has been realised. > > The new implementation has allowed us to fix a few bugs related to the > structure tree representation of tables. > > Thanks, > > Peter > > [1] > http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/201109.mbox/%3C4E6624CE.1030703%40gmail.com%3E
DO NOT REPLY [Bug 52625] border-left / border-right renders incorrectly
https://issues.apache.org/bugzilla/show_bug.cgi?id=52625 --- Comment #2 from Santanu Dutta 2012-02-08 12:42:47 UTC --- Created attachment 28287 --> https://issues.apache.org/bugzilla/attachment.cgi?id=28287 PDF output (XEP v4.19) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 52625] border-left / border-right renders incorrectly
https://issues.apache.org/bugzilla/show_bug.cgi?id=52625 --- Comment #1 from Santanu Dutta 2012-02-08 12:41:33 UTC --- Created attachment 28286 --> https://issues.apache.org/bugzilla/attachment.cgi?id=28286 PDF output (FOP v1.0) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 52625] New: border-left / border-right renders incorrectly
https://issues.apache.org/bugzilla/show_bug.cgi?id=52625 Bug #: 52625 Summary: border-left / border-right renders incorrectly Product: Fop Version: 1.0 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: pdf AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: icyl...@gmail.com Classification: Unclassified Created attachment 28285 --> https://issues.apache.org/bugzilla/attachment.cgi?id=28285 data file If fo:table-cell contains 'none' value specified for border-top or border-bottom, then border-left / border-right renders incorrectly. Sample attached test.fo file is a subset file which is distributed with fop distro and could be named "borders.fo" within example directory. The file being processed through fop (version 0.95 and 1.0), and for both cases output PDF file(test_fop.pdf) are not viewing properly. Border colors are uneven. But the same file being produced with RenderX (test_xep.pdf), views correctly and borders colors found even. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
