[ALF-10870] Blurry preview with latest settings for pdf2swf Created: 18-Oct-11  Updated: 14-Jun-12  Resolved: 05-Dec-11

Status: Closed
Project: Alfresco
Component/s: Document Library, Transformations
Affects Version/s: 4.0.a Community
Fix Version/s: 4.0 Enterprise
Security Level: external (External user)

Type: Bug Priority: Critical
Reporter: Peter Löfgren Assignee: Closed Issues
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Forum poster used 4.0.a, I have tested with r31253.


Attachments: PNG File Blurry flash preview.png     JPEG File screen1.JPG     JPEG File screen2.JPG    
Issue Links:
Related
relates to ALF-14456 Unable to get SWFTools v0.9.2 working... Closed
Date of First Response:

 Description   

With the current default settings for pdf2swf the previews are blurry.
The problem is described in this forum post
https://forums.alfresco.com/en/viewtopic.php?f=47&t=41211



 Comments   
Comment by Peter Löfgren [ 18-Oct-11 ]

Left side shows preview with
pdf2swf -T 9 -s zoom=72 -s ppmsubpixels=1 -s poly2bitmap=1 -s bitmapfonts=1

right part shows preview with
pdf2swf -T 9 -s zoom=72 -s ppmsubpixels=1

Comment by Peter Löfgren [ 18-Oct-11 ]

To clarify somewhat, the left side is the current default in alfresco/subsystems/thirdparty/default/swf-transform.properties.
Changes are due to ALF-9417. Even if the changes are an improvement for graphics heavy pdfs, I think the default value must be changed to give better output.
Workaround is of course to add your preferred swf.encoder.params to alfresco-global.properties.

Comment by akovalchuk [ 18-Oct-11 ]

The -s bitmapfonts=1 makes this difference. It was introduced for performance reason for processing large documents. I think it would be better to document this clearly to allow user to change such settings according to their needs.

Comment by Gavin Cornwell [ 18-Oct-11 ]

I tend to agree with Arseny, if the new options are going to give a worse result 80% of the time I think we should consider removing the options and release note the original issue that they were added for.

Raising to critical as this may potentially effect a lot of customers.

Comment by Gavin Cornwell [ 03-Nov-11 ]

Having investigated this issue further I have changed my mind on the course of action we should take.

The addition of the "poly2bitmap" parameter was done quite a while ago and it was to address JVM crashes, not just for performance reasons, see ETHREEOH-3023 and ALF-3580.

I would therefore rather not remove options that prevent JVM crashes in favour of blurry previews in some cases (all the PDFs I tested with seemed fine).

As there is a fairly simple workaround available (as noted above) and we're never going to have a set of options that are perfect for every PDF out there I'm going to release note this issue.

Comment by Gavin Cornwell [ 03-Nov-11 ]

I have added this to the release notes (https://wiki.alfresco.com/wiki/Alfresco_Community_4.0.b_Release_Notes#Known_Issues) and suggested the workaround above be applied.

Comment by Peter Löfgren [ 04-Nov-11 ]

I agree that for now blurry preview is preferred over JVM crash. But this is just hiding the underlying problem, that executing an external binary can cause JVM to crash. And the blurry preview is something everyone will see, making Alfresco look like and inferior product. With that I mean what the end user notice, they don't immediately think of JVM stability (until they notice the system is down of course).

So I suggest you open a new issue for tracking if

  • there are some changes that can be done in how Alfresco call external binaries (not just for pdf2swf) that in case of the external binary crashing prevents the JVM to crash

It may be that it is a fundamental flaw in Java, that there is no way Alfresco can prevent a JVM crash. Still think a new issue should be opened just to track the underlying issue.

Comment by Ravi Manthena [X] (Inactive) [ 14-Nov-11 ]

Assigned to Alfresco QA Team for testing.
Please use head build 643 and SVN revision number 31912 or later to test this issue.

Comment by Alfresco QA Team (Inactive) [ 22-Nov-11 ]

The issue was reproduced on Alfresco Test v4.0.0beta build 643, Tomcat, PostgreSQL, Java 6 (all installer deployed) Client: WinXP SP3 x32, FF8.

I've changed swf-transform.properties and used the followong settings:

1) swf.encoder.params=-s zoom=72 -s ppmsubpixels=1 (screen1.jpg)

2) swf.encoder.params=-s zoom=72 -s ppmsubpixels=1 -s poly2bitmap=1 -s bitmapfonts=1 (Default settings - screen2.jpg)

VadimZh

Comment by Gethin James [X] (Inactive) [ 05-Dec-11 ]

When i remove the -s bitmapfonts=1 and then preview a large pdf I get the following error:
Caused by: org.alfresco.service.cmr.repository.ContentIOException: 11050006 Transformation failed - status indicates an error:
Execution result:
os: Mac OS X
command: [/Users/gjames/development/bin/utilities/pdf2swf, -T, 9, -s, zoom=72, -s, ppmsubpixels=1, -s, poly2bitmap=1, /temp/Alfresco/RuntimeExecutableContentTransformerWorker_source_7903128639659146203.pdf, -o,
/temp/Alfresco/RuntimeExecutableContentTransformerWorker_target_5191484155848073984.swf]
succeeded: false
exit code: 1
out: NOTICE processing PDF page 1 (612x792:0:0) (move:0:0)

err: pdf2swf(4447,0xacaf92c0) malloc: *** error for object 0x56f4a0: pointer being freed was not allocated

      • set a breakpoint in malloc_error_break to debug
        pdf2swf(4447,0xacaf92c0) malloc: *** error for object 0x567400: pointer being freed was not allo
        at org.alfresco.repo.content.transform.RuntimeExecutableContentTransformerWorker.transform(RuntimeExecutableContentTransformerWorker.java:272)
Comment by Gethin James [X] (Inactive) [ 05-Dec-11 ]

I tried another pdf file without the bitmapfonts=1 param and pdf2swf stays on 100% cpu indefinitely.

The current settings seem to represent the best trade off between performance and swf preview quality. Individual installations can experiment with these parameters but for a standard install these seem the most appropriate settings.

Comment by Peter Löfgren [ 05-Dec-11 ]

This cannot be set to wont fix, because the blurry previews look like awful. Just because you for the moment haven't found a suitable fix, you cannot hide the issue. The blurry preveviews are still there and needs to be fixed. So I think it is better to change the "Fix versions" or something rather than closing as "Won't fix"

Comment by Ravi Manthena [X] (Inactive) [ 14-Dec-11 ]

Assigning to Alfresco QA Team for testing
please use build-00733 or later

Comment by Alfresco QA Team (Inactive) [ 20-Dec-11 ]

Successfully validated on Alfresco EE 4.0 (build 733), RHEL 5.5 x64, Tomcat 6.0.0.29, PostgreSQL 9.0.2, Java 1.6.0.22 (all from installer). Client: Win 7 x64, FF8

Comment by Richard Esplin [X] (Inactive) [ 13-Jun-12 ]

Linking to other issues related to the same setttings.

Generated at Fri Sep 25 20:44:19 BST 2020 using Jira 7.13.15#713015-sha1:7c5ddd2c3e1709974ae9c48c17df8edd3919fe2c.