I'm getting the stacktrace below printed to my log/console. I'm using Tomcat 6.0 and BIRT 2.6.2. It's not stopping the viewer from displaying reports, but it is taking up precious space in the log.
I found someone having a similar problem here, but there's no clear indication as to what the resolution was. Like the poster in that link, I am in the middle of upgrading to a new version of BIRT (2.6.2).
Let me know if you need any more information about my setup. I'm fairly new to BIRT. Any help is welcome, even if you can suggest a place to look.
java.io.IOException: Content is not allowed in prolog.
at org.apache.batik.dom.util.SAXDocumentFactory.createDocument(Unknown Source)
at org.apache.batik.dom.util.SAXDocumentFactory.createDocument(Unknown Source)
at org.apache.batik.dom.svg.SAXSVGDocumentFactory.createDocument(Unknown Source)
at org.apache.batik.dom.svg.SAXSVGDocumentFactory.createDocument(Unknown Source)
at org.apache.batik.transcoder.XMLAbstractTranscoder.transcode(Unknown Source)
at org.apache.batik.transcoder.SVGAbstractTranscoder.transcode(Unknown Source)
at org.eclipse.birt.report.engine.util.SvgFile.transSvgToArray(SvgFile.java:78)
at org.eclipse.birt.report.engine.util.SvgFile.transSvgToArray(SvgFile.java:58)
at org.eclipse.birt.report.engine.emitter.html.HTMLReportEmitter.handleStyleImage(HTMLReportEmitter.java:3423)
at org.eclipse.birt.report.engine.emitter.html.AttributeBuilder.buildBackground(AttributeBuilder.java:114)
at org.eclipse.birt.report.engine.emitter.html.HTMLVisionOptimize.buildStyle(HTMLVisionOptimize.java:106)
at org.eclipse.birt.report.engine.emitter.html.HTMLReportEmitter.outputCSSStyles(HTMLReportEmitter.java:906)
at org.eclipse.birt.report.engine.emitter.html.HTMLReportEmitter.start(HTMLReportEmitter.java:722)
at org.eclipse.birt.report.engine.emitter.CompositeContentEmitter.start(CompositeContentEmitter.java:225)
at org.eclipse.birt.report.engine.api.impl.RunAndRenderTask.doRun(RunAndRenderTask.java:179)
at org.eclipse.birt.report.engine.api.impl.RunAndRenderTask.run(RunAndRenderTask.java:77)
at org.eclipse.birt.report.service.ReportEngineService.runAndRenderReport(ReportEngineService.java:928)
at org.eclipse.birt.report.service.BirtViewerReportService.runAndRenderReport(BirtViewerReportService.java:973)
at org.eclipse.birt.report.service.actionhandler.BirtRunAndRenderActionHandler.__execute(BirtRunAndRenderActionHandler.java:76)
at org.eclipse.birt.report.service.actionhandler.AbstractBaseActionHandler.execute(AbstractBaseActionHandler.java:90)
at org.eclipse.birt.report.presentation.aggregation.layout.EngineFragment.doService(EngineFragment.java:318)
at org.eclipse.birt.report.presentation.aggregation.AbstractBaseFragment.service(AbstractBaseFragment.java:76)
at org.eclipse.birt.report.servlet.BirtEngineServlet.__doGet(BirtEngineServlet.java:120)
at org.eclipse.birt.report.servlet.BaseReportEngineServlet.doGet(BaseReportEngineServlet.java:185)
at org.eclipse.birt.report.servlet.BaseReportEngineServlet.doPost(BaseReportEngineServlet.java:224)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.eclipse.birt.report.servlet.BaseReportEngineServlet.service(BaseReportEngineServlet.java:116)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.eclipse.birt.report.filter.ViewerFilter.doFilter(ViewerFilter.java:68)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:722)
This is from entering the background image property in the style of a report design.
In CSS, the backgroundImage property requires url('path/to/image.jpg').
body {
background-image:url('path/to/image.jpg');
}
However BIRT appears to be rendering the following for the style:
body {
background-image:'path/to/image.jpg';
}
In order to get around this I entered the following in the initialize script for every report design that uses the backgroundImage style:
reportContext.getDesignHandle().findStyle("blueresultsetheaderrow").backgroundImage = "url('images/BlueSortTitleBar.gif')";
I suspect that this is a bug, so I logged this one.
Related
Does modern Windows provide some sort of hooks that would allow a developer to change pixel values before they reach the GPU/are sent to the display?
For example to convert the whole desktop to monochrome independent of the applications currenly displayed (perhaps even including games).
Something that could work along side an existing (closed source) display driver.
Copying the iText7 JumpStart Tutorial Chapter 3 Handling Events code and running it in eclipse is generating a ClassCastException. Exception in thread "main" java.lang.ClassCastException: com.itextpdf.kernel.color.DeviceRgb cannot be cast to com.itextpdf.layout.property.TransparentColor.
If I comment out the line canvas.setProperty(Property.FONT_COLOR, Color.WHITE); in that example http://developers.itextpdf.com/content/itext-7-jump-start-tutorial/examples/chapter-3#1744-c03e03_ufo.java the PDF is created with no error. But the watermark obviously isn't applied correctly. How can I fix the ClassCastException in this example?
The problem is easily fixed, since TransparentColor has a constructor that takes an ordinary color as argument.
// Add watermark
Canvas canvas = new Canvas(pdfCanvas, pdfDoc, page.getPageSize());
canvas.setProperty(Property.FONT_COLOR, new TransparentColor(Color.WHITE));
canvas.setProperty(Property.FONT_SIZE, 60);
canvas.setProperty(Property.FONT, helveticaBold);
canvas.showTextAligned(new Paragraph("CONFIDENTIAL"), 298, 421, pdfDoc.getPageNumber(page), TextAlignment.CENTER, VerticalAlignment.MIDDLE, 45);
Alternatively, you could also use
canvas.setFontColor(Color.WHITE);
I'll see about updating the examples on the iText website.
Thanks for your input!
What is the issue which will cause the app crash when a user opens the app?
I integrate with HockeyApp, the error shown:
VMRuntime.newNonMovableArray java.lang.OutOfMemoryError: Failed to allocate a 63701004 byte allocation with 16777056 free bytes and 41MB
until OOM
Xamarin caused by: java.lang.OutOfMemoryError: Failed to allocate a 63701004 byte
allocation with 16777056 free bytes and 41MB until OOM
dalvik.system.VMRuntime.newNonMovableArray(Native Method)
android.graphics.BitmapFactory.nativeDecodeStream(Native Method)
android.graphics.BitmapFactory.decodeStreamInternal()BitmapFactory.java:639
android.graphics.BitmapFactory.decodeStream()BitmapFactory.java:615
android.graphics.BitmapFactory.decodeStream()BitmapFactory.java:653
Answer
I already solve the problems with
Update the Xamarin.Forms Nuget.
Delete the package file in the solution.
Build the Solution again.
Add in your manifest these lines android:hardwareAccelerated="false" , android:largeHeap="true" it may solve your issue(s).
<application
android:allowBackup="true"
android:hardwareAccelerated="false"
android:icon="#mipmap/ic_launcher"
android:label="#string/app_name"
android:largeHeap="true"
android:supportsRtl="true"
android:theme="#style/AppTheme">
I had the same issue. It turned out that multiple changes solved the problem.
Firstly, I ensured that my app can deal with large memory heaps. This is a setting you can set/change in the app's manifest:
<application
...
android:largeHeap="true"> <!-- This line does the trick. -->
Secondly, I made sure that I enforce small image sizes wherever possible. In my case I decided to limit the max resolution to either 720 pixels or the screen resolution, whatever is smaller. As a result I resized large images:
int maxImageSideLength = Math.Min(720, Math.Max(myScreenHeight, myScreenWidth));
// see tutorials how to resize the image now
Lastly, I ensured to dispose image bitmaps (used memory) that where assigned to image views before I assigned a new image. I am uncertain whether this is really necessary as I can't believe that assigning a new image bitmap isn't cleaned up properly, but I left this in my code and I am still happy with a smoothly running app. Example:
Bitmap resizedImage = ResizeImage(fileName, maxImageSideLength);
imageView.SetImageBitmap(null); // this is to free allocated memory
imageView.SetImageBitmap(resizedImage);
GC.Collect(); // dispose of the Java side bitmap
I've been working on a Skrollr site but it appears to be getting excessively jerky. I've had dev tools open and have found a few really really slow frames, but I don't have the knowledge to track down exactly what is going wrong.
My observations are:
it is slower scrolling down than up
intermittently it is absolutely fine
So far I have tried a few things
Given the first segment a translateZ value to try and separate out the paint (I have no idea if this is correct – I'm really at the limit of my knowledge!)
Had a go getting rid of the relative animations (data-top-bottom etc) which could well be slowing things down, but after changing everything back to static numbers (data-1000 etc) its still almost identical
Can anyone shed any light on this? The URL is http://fieldviewfestival.co.uk/500 ... power up!
I think I've fixed it!
The webfonts weren't fully loaded when skrollr kicked in. After initializing it I added a
$(window).load(function(){
Where I refreshed skrollr I then added the following:
s.refresh();
I think the main problem was that the height of the page wasn't calculated by the time skrollr kicked in.
Also I had a strange scrollbar left over (so a scrollbar on the body AND html), which skrollr hadn't removed so I also added above that function
$(window).trigger('resize');
The final initialize looks like this:
var s = skrollr.init();
$(window).load(function(){
// console.log("Loaded");
$(window).trigger('resize');
s.refresh();
});
NB Silly miskate I made as well, don't use the function $(document).load(
I got an exceedingly strange problem. I have a SidebarDocumentsIcon.icns file (the same one used by finder) that I load into an NSImageWell. However, at certain critical sizes(width between 17-18 pixels) my image becomes completely scrambled in both the interface builder and the compiled app. This only happens to certain images for some reason, and never used to happen before. I tried to restore my repository, made sure that every byte is in the right place, but still this annoying bug keeps on happening. Has anybody here experienced this problem before? Any tips on solving it?