I don't know if "cutting" is the right term...
I've got to finish doing a large and complex report based on an Applet legacy system, a fellow and I decided trying reuse all the logic in the applet to avoid the complexity of doing a lot of sub-reports. What we did was copy all the logic in the applet that include a lot of condictionals/SQL and make a huge and properly formated String, so that in our Jasper file it would just have a method called "myVo.getBody()" besides the header and footer stuff.
Unfortunately we found out a problem that some part of text get lost between pages. I think that as the text get bigger and reach Jasper page limit for some reason it keeps being writed in a "no visible area" and when the next page content starts some part was lost.
For example, there is a list of 19 items and what happens is:
End of 2nd page
1 - item
2 - item
beggining of 3rd page
18th - item
19th - item
Items from 3 to 17 are not being showed.
Is there any Jasper configuration for this situation?
We tried:
Position type: Fix Relative to the Top and Float
Stretch Type: Relative to the Tallers Object and Relative to Band Height
Stretch With Overflot: true or false
I don't think showing Java code would be useful as it just use a StringBuffer to build the String, put it on body property in a PreparedDocumentVO so that Jasper model can consumes it. It seems to be some Jasper setting, or the idea of creating a huge String is not so good as we thought.
I would consider breaking the result up.
Jasper formats information based on a relative page size. This means that at some point in time, when dealing with information that is not likely to fit on a page, Jasper will probably make an assumption that doesn't hold (and your data will likely not be formatted into the page).
If you have an exceptionally long string, consider splitting it up. Besides, people scroll web pages down, not the side, so a heavy side-scrolling document is likely to cause user issues unless every record scrolls to the side just as heavily.
Related
I'm building a website for a friend who's writing a novel, and want to display it, chapter by chapter, in a book-like display, with pages turning.
I have a frontend app in Angular 2 and a backend in Java (as they're the tools I'm more familiar with). A backoffice on the Angular app allows the user to add the text of a chapter, which is sent to the backend to be stored in the DB. Then the front of the Angular calls the backend to retrieve the chapter, and has to display it in the book-like display.
My problem is how can I split the text of the chapter into pages in order to display it. I could change the backoffice to force the user to add the text page by page. I could ask the user to put a specific marker in the text to indicate a page break. But I'ld like the process to be as transparent as possible for the user.
So I went for a solution by splitting the text on the backend. I estimated how many characters are on a line, and how many lines are on a page, then I cut the text accordingly (with some adjustments, as it's a HTML text with tags in it).
But it feels like a very strict approach, as I'm choosing the size of a page, regardless of the display interface size.
So I'm wondering if there is a better approach :
- a different splitting algorithm
- a tool front-side to display my text without splitting it
- something else
Does anyone had to face a similar problem ?
Thanks
You are performing that action on server side that has no sense of the page length.
I assume that a better approach shall be to get the complete chapter from backend to front end; and have a front end function that will calculate :
- the number of characters per lines based on page size
- the number for line based on page size
- the number of chapter pages based on previous info
This is a way better approach than your full backend ones.
However; this is not a responsive approach.
Do you have interest and need within a responsive one ?
If yes; you may add a watch on the page length/height to recalculate the above values and re generated your pages
I have a large richfaces tree and each element in the tree can be selected which loads the content via AJAX and edited which redirects you to a new page. This was working great until I had a particularly large document I was working on and saving no longer worked. You got redirected to the edit page which showed the right content, but trying to "save" any edits resulted in a ViewExpiredException.
I tried tweaking a lot of parameters and eventually arrived at two parameters that fixed it:
com.sun.faces.numberOfViewsInSession
com.sun.faces.numberOfLogicalViews
As far as I can see, the default for each is 15, I set them to a ridiculous 500 and the application works again. Unfortunately because I don't know where the problem is situated and it's a large application I can't show you any relevant code.
But the questions are: what exactly do these parameters do, what could cause me to bump into these exceptions and what are acceptable values?
UPDATE
I'm not entirely sure why the question got downvoted but if it is with regards to the supposed duplicate: I had found that post through google but the link it provides is dead. Except for the bog standard (and vague) definition of the parameters, there does not seem to be much information on them.
When server side state saving is used (which is default) than those two parameters can be used to configure maximum number of logical and actual views.
Logical view is top level view which is created on every GET request (for example when you open page in new browser window or tab, entering address in address bar of browser, iframes...). Each logical view can have some number of associated actual views. Actual views are created as user navigate through your pages with standard JSF mechanisms (for example if you navigate to page returned from action methods in commandButton). Both queues of views use LRU algorithm to decide when view will be removed, and maximum number of those queues are limited by values of these two parameters.
So, com.sun.faces.numberOfViewsInSession defines the maximum number of JSF views stored in the session for per logical view, and com.sun.faces.numberOfLogicalViews defines the maximum number of logical views to store per session.
According to information you provided a suspect that configuration of com.sun.faces.numberOfViewsInSession solved your problem, but you must further investigate why is created so many views.
Additional link:
What are the differences between Server and Client side state saving and what are the benefits/drawbacks of each?
I am adding a link to a report generated with fictitious information, in case someone wants to look at the presentation.
As can be seen on page 5, three texts are printed, but
the third did not fit completely. The rest of it is presented on page 6. I needed it to be printed in full on page 6 (note: The dashes serve to demarcate the end of the field).
Found: isStretchWithOverflow, isPrintWhenDetailOverflows and, as
splitType put the band as Prevent. But this did not work as desired.
Any other tips?
I resolved the problem by setting splitType as Prevent.
I created a report page with A4 format in iReport4.5 and use in java application.
how to change A4 to A5 format on runtime in java application?
Before I show you how to do this, please note that just changing the Page Size is probably not going to give you what your want. It will make the page larger or smaller depending on what you want, put the positioning of elements will not change. IN your case the report may not even compile depending on where you have items laid out.
You do have a couple options though:
First you could create a second report for the A5 format, and then
at run time grab the appropriate report depending on what you want.
This is probably the easiest solution, but it does mean you end up
with almost 2 identical reports. Meaning any changes in the future
you would have to do in two places.
Second if it is a fairly straight forward report with a typical
layout you could use something like Dynamic Jasper to generate your
report in java code.
Lastly you could work directly against the Jasper Report's API to
generate your report at run time.
Now to answer your question. First load up the JRXml file into a JasperDesign object:
//Note JRXMLLoader could also take a File object or
//InputStream instead of a String as the parameter.
JasperDesign design = JRXmlLoader.load("report.jrxml");
Once you have the JasperDesign you can set the page size to what ever you want. A5 paper from what I can tell is 5.83" × 8.27". To convert this to a size that JasperReports understands multiply each by 72, getting you 420 x 596 (I rounded as we have to set Integers).
design.setPageHeight(596);
design.setPageWidth(420);
From there you cointinue on your exporting adventure as you normally would.
We need to load and display large files (rich text) using swing, about 50mb. The problem is that the performance to render the files is incredibly poor. We tried both JTextPane and JEditorPane with no luck.
Does someone have experience with this and could give me some advise ?
thanks,
I don't have any experience in this but if you really need to load big files I suggest you do some kind of lazy loading with JTextPane/JEditorPane.
Define a limit that JTextPane/JEditorPane can handle well (like 500KB or 1MB). You'll only need to load a chunk of the file into the control with this size.
Start by loading the 1st partition of the file.
Then you need to interact with the scroll container and see if it has reached the end/beginning of the current chunk of the file. If so, show a nice waiting cursor and load the previous/next chunk to memory and into the text control.
The loading chunk is calculated from your current cursor position in the file (offset).
loading chunk = offset - limit/2 to offset + limit/2
The text on the JTextPane/JEditorPane must not change when loading chunks or else the user feels like is in another position of the file.
This is not a trivial solution but if you don't find any other 3rd party control to do this I would go this way.
You could use Memory Mapped File I/O to create a 'window' into the file and let the operating system handle the reading of the file.
Writing an efficient WYSIWYG text editor that can handle large documents is a pretty hard problem--Even Word has problems when you get into large books.
Swing is general purpose, but you have to build up a toolset around it involving managing documents separately and paging them.
You might look at Open Office, you can embed an OO document editor screen right into your app. I believe it's called OOBean...
JTextPane/JEditorPane do not handle well even 1mb of text (especially text with long lines).
You can try JEdit (StandaloneTextArea) - it is much faster than Swing text components, but I doubt it will handle this much text. I tried with 45m file, and while it was loaded (~25 seconds) and I could scroll down, I started getting "outofmemory" with 1700m heap.
In order to build a really scalable solution there are two obvious options really:
Use pagination. You can do just fine with standard Swing by displaying text in pages.
Build a custom text renderer. It can be as simple as a scrollable pane where only the visible part is drawn using BufferedReader to skip to the desired line in the file and read a limited number of lines to display. I did it before and it is a workable solution. If you need to have 'text selection' capabilities, this is a little more work, of course.
For really large files you could build an index file that contains offsets of each line in characters, so getting the "offset" is a quick "RandomAccess" lookup by line number, and reading the text is a "skip" with this offset. Very large files can be viewed with this technique.