Skip navigation
All Places > Alfresco Content Services (ECM) > Blog > 2018 > May
2018

We’ve received your feedback since we took the AddOns site offline on May 25th and I can appreciate people’s disappointment in seeing this resource being seemingly taken away, especially for those Community members who’d worked hard on creating AddOns.

 

I wanted to pause and answer to some of the questions that have come up in the community since:

 

Why did we take the site offline?

During an internal audit of all of our sites and systems ahead of GDPR we found out that there were some serious problems with the AddOns site security. The AddOns site stored personally identifiable information and with GDPR compliance looming, we took the difficult decision to take the site offline.

 

What we’re doing now

In the next 5-10 days, we’re going to create a version of the AddOns directory inside of the existing Alfresco Community website and import the previous add-ons to that space. Kristen Gastaldo is working on that, so expect to see some content in the next few days.

 

What we’re doing in the future

We’re currently gaining momentum internally on building what is next for an Alfresco AddOns / Extensions directory and we’d like to hear from you on how we can make it bigger and better than the AddOns site that went before.

Unfortunately we’ve had to temporarily remove access to addons.alfresco.com - we understand that you may be disappointed, we’re working on bringing it back in a read-only mode whilst we work out what the next steps for the Alfresco AddOns Community.

 

We’d love to hear more from you on your thoughts on how we can move AddOns forward as we begin planning the next evolution of the Alfresco Community we kindly invite you to contact us with a message. We will do our best to face and solve the issue as soon as possible. We sincerely hope that this won't cause problems to anyone. If it will happen, we apologise in advance.

 

Update of 7th of June - You can find the draft of the static list at Alfresco Addons *Incomplete list* 

 

About Alfresco AddOns

 

If you have ever customised or extended Alfresco Content Services (and/or Alfresco Share), you might have found a website called addons.alfresco.com. Alfresco Add-on website is a large collection of customisations and extensions for the Alfresco platform, contributed by the company's global developer community. The Alfresco Add-on website was designed to be a one-stop shop for Alfresco users looking to extend the functionality of Alfresco with pre-built modules.

 

The Alfresco Add-on website has been active since 2012 and since the beginning it grew rapidly, hosting several hundreds of different projects: Open Source and Proprietary, developed by Alfresco official partners or Community enthusiasts, supported or "given as is" in terms of production readiness. From this point of view, the initiative has been a success and a positive achievement of the entire Alfresco ecosystem (Alfresco as a Company, partners, customers, users, enthusiasts, etc.).

 

Most of the Alfresco enthusiasts agree that a sort of "Alfresco Marketplace" would be something useful for everyone, even if some concerns were around since a long time about the (proven) level of maturity of the (oldest) releases of the projects with the newest versions of Alfresco Content Services (and Alfresco Share). In addition to that, an improved experience in searching and installing the add-ons were something suggested, but never discussed and defined with enough details.

 

Today the GDPR is forcing us to the decision to put the Alfresco Add-on website in stand-by mode, until its future version will be defined and re-launched again. Looking forward to start the discussion around the next version of the Alfresco Marketplace, Add-on mechanism or whatever it will be.

Alfresco is delivering a Docker Compose for ACS Community deployment that can only be used for local testing environments:

 

acs-community-deployment/docker-compose at master · Alfresco/acs-community-deployment · GitHub 

 

In order to deploy the product in real environments, some additional configurations must be performed. You can find some of this configurations described at Using Alfresco 201804-EA in a simple PROD environment 

 

However, as it should be advisable to maintain original Alfresco resources untouched, another approach is required. Docker Compose allows to share configuration by using additional YML specification files to override the original one. Below some instructions to configure default Alfresco Docker Compose for ACS 6 Community are provided.

 

Checkout or download official Docker Compose

 

$ git clone git@github.com:Alfresco/acs-community-deployment.git
Cloning into 'acs-community-deployment'...
remote: Counting objects: 145, done.
remote: Compressing objects: 100% (91/91), done.
remote: Total 145 (delta 79), reused 103 (delta 49), pack-reused 0
Receiving objects: 100% (145/145), 27.53 KiB | 240.00 KiB/s, done.
Resolving deltas: 100% (79/79), done.

$ cd acs-community-deployment/docker-compose/

$ ls
docker-compose.yml

 

Create a docker-compose.override.yml file

 

You can add volumes mapping, ports exposition and additional Docker images to original Docker Compose.

 

$ touch docker-compose.override.yml

$ cat docker-compose.override.yml
version: "3"

services:

    httpd:
        build: ./httpd
        ports:
          - 443:443
        links:
          - alfresco
          - share
          - solr6 

    alfresco:
      volumes:
          - ./data/alf-repo-data:/usr/local/tomcat/alf_data
      ports:
          - 21:2121

    postgres:
      volumes:
          - ./data/postgres-data:/var/lib/postgresql/data

    solr6:
      volumes:
          - ./data/solr-data:/opt/alfresco-search-services/data

 

Add your customised images

 

Adding an NGIX or Apache HTTPd server should be recommendable for many environments.

 

$ tree httpd
httpd
├── Dockerfile
└── assets
    ├── CA.pem
    ├── alfresco-vhost.conf
    ├── server.crt
    └── server.key

 

You can use something provided by the Community like this one, or any other you like.

 

Start the composition

 

You can use default commands to run Docker Compose.

Extensions declared in docker-compose.override.yml file will be picked automatically, so your volumes, ports and additional Docker images will be available in the composition.

 

$ docker-compose up -d --build

 

Now Alfresco is running in a real environment by using official (and untouched) Docker Compose resource.

It is time, at last, to announce the release of the Records Management Community 2.7.b, which follows 2.7.a from February and brings improvements over the existing features, mostly on auditing events and on the search results.

 

What's in 2.7.b?

In this release, we have focused more on fixing audit bugs, for instance, event filtering (RM-5794, RM-5234), logging user creation and deletion (RM-5235) and logging group events (RM-5236).

 

Another noteworthy improvement is that we have also fixed a security issue (RM-6275) and a few bugs on the search feature, including GROUP_EVERYONE disappearing from search results after installing RM module (RM-2504).

 

Also on the records search results, we have introduced a new component in the metadata, the Record Category Identifier that refers to the record category that is the first in the record primary parental hierarchy (RM-6137).

For those who missed the wiki pages, now they can enjoy the feature again as the bug of not being able to create new pages has been fixed (MNT-19114).

 

What's coming up next?

 

Most significantly, compatibility with community release of ACS 6.0.x is our priority for the next release in AGS 3.0.a, and as usual we will continue to keep you updated on this.

 

We are really interested to hear about your feedback on 2.7.b or on anything that you would like to see in our future releases. You may use both the comments below or consider writing a message to any of the team members.

 

Links

 

A while ago, Alfresco decided to replace the Ghostscript engine in our products. It has been used as a rasteriser to transform PDF files to PNG images within Alfresco Content Services (ACS). The main cause was due to Ghostscript’s change to an AGPL license, which caused some concerns among our customers and limited us in the way how we could distribute ACS.

 

Alfresco Engineering was tasked to evaluate different options for PDF rendition under a permissive open source license. Unfortunately, we found almost no independent performance and fidelity comparison between the different engines out there — especially no study that is thorough enough to base such a decision on. Since the new engine will be used as the default in our next version of ACS, it would have the potential to cause severe problems for our customers if it fails either due to poor performance or poor fidelity.

 

In the end, we decided to do this study ourselves. With this blog post, we want to share our results with you.

 

Market Overview

After research on Wikipedia and Google, our team came up with this list of PDF rendering engines:

EngineLicenseNotes
GhostscriptAGPLv3 or CommercialFull PostScript interpreter. Can also handle PDF files.
MuPDFAGPLv3 or CommercialPDF, XPS and EPUB rendering engine based on the modern high performance Fitz graphics engine
Adobe PDF Library SDKCommercialOriginal Adobe PDF engine.
Foxit SDKCommercialEngine behind the Foxit PDF reader products.
Fork released under BSD license as Pdfium by Google.
PdfiumBSD styleEngine behind PDF Plug-In in Chrome.
Fork of the Foxit SDK.
PopplerGPLv2 or GPLv3Fork of XPdf
XpdfGPLv2 or CommercialPDF viewer for X-Windows & PDF Rasterizer for all platforms (pdftopng). 
GnuPDFGPLv3
PDFBox 2.0Apache 2.0
SejdaAGPLv3 or Commercial
IcePDFApache 2.0 and Commercial Pro version
Aspose PDFCommercial

(Note: There are multiple PDF Reader products out there, but this is the consolidated list of PDF rendering engines behind these products)

 

The Candidates

Given our constraints on license terms and other factors, we decided to start our deep and thorough investigation with this list of candidates. We included some leading proprietary libraries for reference.

EngineTypeVersion
GhostscriptNative9.21
MuPDFNative1.10a
XpdfNative3.04
PdfiumNative2017-04-10
AsposeJava17.2.0
ICEPdfJava6.2.0
SejdaJava3.0.13
PDFBoxJava2.0.5

The version numbers are the latest released version at the time of our investigation.

 

Performance

Ghostscript has been used until ACS 5.1 to render all PDF files to PNG images for things like thumbnails. Most other file formats, like MS Office files, are converted to PDF first for previewing and then the PDF is converted to PNG. In our analysis, we have been interested in the average overall performance.

Our team randomly picked 3071 PDF documents (17,226 pages) from our internal Alfresco Repository to get a sample set representing a typical ACS repository. We are aware that there are ACS installations out there that mainly contain documents of one specific kind, but we are confident that our sample set represents the majority of ACS repositories.
To compare the performance, we rendered all documents to PNG files at 100 dpi. Each engine was configured to produce results at comparable fidelity (e.g. by activating anti-aliased text and graphics) and we guaranteed the same resources to each engine. For all Java based engines, we kept the JVM running and invoked the rendition for each document in the same JVM process, enabling Hotspot to best optimise the generated native code.
This led to the following total process times:

Rendition times of different PDF engines

(total rendition time; smaller is better)

 

We played with different dpi settings to see how the results would change. We found that the relative difference between engines is affected by the resolution (dpi), but the order in which the candidates ranked stayed the same across different dpi settings (except for close candidates).

 

Our key findings are:

  • Native engines are always faster than Java based engines
  • MuPDF is clearly the fastest engine
  • Pdfium comes in second, but is significantly slower than MuPDF

 

Features  and Fidelity

Because our new transformation engine will be used for a server based rendition of PDF documents to PNG files, all interactive features like form filling, signature validation, video or 3D were out of scope for our investigation.

 

Based on the latest PDF specification, we compiled a list of features that are provided by the PDF drawing model. For each feature, we picked a sample document for testing or created such a document ourselves. The rendition of these sample documents was then visually compared and rated. We used the latest Adobe Acrobat Reader as our reference viewer.

 

Text rendition and font support

 

Text  rendition & font support

Ghostscript

MuPDF

Xpdf

Pdfium

Aspose

ICEPdf

Sejda

PDFBox

Type1

4

5

4

5

1

1

4

4

TrueType

4

5

4

5

4

0

5

5

Type1 CID

yes

yes

yes

yes

yes

no

yes

yes

TrueType CID

yes

yes

yes

yes

yes

no

yes

yes

Type3

3

5

6

6

1

0

1

1

AVG

3.67

5

4.67

5.33

2

0

3.33

3.33

 

We awarded 0 to 5 points for each rendition compared to the Acrobat reference. In two situations, we awarded an extra point for visually better results than Acrobat.

(click to enlarge)

 

Images

PDF supports 6 different “filters” (i.e. compression formats) that can be used to store raster graphic data. The decoded raster graphic then needed to be mapped to the pixels of the rendered output graphic. This process has a huge impact on the final visual result.

 

Images

Ghostscript

MuPDF

Xpdf

Pdfium

Aspose

ICEPdf

Sejda

PDFBox

Anti Aliasing

no

yes

yes

yes

no

partial

no

no

CCITTFaxDecode

yes

yes

yes

yes

yes

yes

yes

yes

DCTDecode

yes

yes

yes

yes

yes

yes

yes

yes

LZWDecode

yes

yes

yes

yes

yes

yes

yes

yes

FlatDecode

yes

yes

yes

yes

yes

yes

yes

yes

JPXDecode

yes

yes

yes

yes

no

partial

no

no

JBIG2Decode

yes

yes

yes

yes

yes

yes

partial

partial

SUM Image

3

5

5

5

2

2

1

1

 

Every engine starts with 5 points. We removed 1 point for each missing filter support and we removed 2 points for non-working anti aliasing.

 

Drawing model

We noticed that the atomic drawing operations (MoveTo, LineTo, CurveTo) and shading models are supported almost equally in all candidates. Visually different results on complex drawings are mainly caused by the composition of these atomic building blocks, and not by the basic operations themselves.

This is why we decided to focus on the composition of drawing operations for our comparison.

 

Compositing and Blend Modes

PDF supports 16 different blend modes. These can either be applied to single objects or to multiple objects in a transparency group. Each blend mode affects the image channels individually and thus produces different results in different colour spaces (RGB, CMYK).
We used a set of test and reference PDF files (link these two for RGB and CMYK) and counted the errors made by each engine. We then used the relative number of errors to assign points, with 5 points being awarded for the fewest errors averaged over all test files and 0 points representing lots of errors. Here are the final results:

 

Blend Modes

Ghostscript

MuPDF

Xpdf

Pdfium

Aspose

ICEPdf

Sejda

PDFBox

AVG

3.33

3.33

3

2

1.67

1

2

2

 

Fidelity results

Combining all of the above gives the following results for features and fidelity:

(rendition fidelity; larger is better)

 

Conclusion

MuPDF came out of this investigation as the clear winner, followed by Pdfium second. It also became apparent that there is big gap between native PDF renderers and the group of Java based PDF renderers — considering performance as well as features and fidelity.

We ended up selecting PDFium as the PDF rasterization engine for these reasons:

  • The BSD-style license of Pdfium gives us and our customers the most flexibility
  • Since this engine drives the PDF display in Chrome, we expect a very good and continued support from Google for this library, especially when it comes to finding and fixing vulnerabilities
  • It shows a very good overall performance, although it is not the fastest engine in the test
  • It shows very good rendition fidelity

 

The Alfresco PDF Renderer

Based on the Pdfium library, we started a new project: the alfresco-pdf-renderer. This native command line program is inspired by the test application used within the Pdfium builds. But it does not provide support for JavaScript and offers additional parameters to specify the size of the output image.

There are great resources inside this Community on how to deploy Alfresco 6 using Docker Compose

Although some real environments will require Kubernetes deployment, many others will be managed with a simple Docker Composition. This post is based in Alfresco 201804-EA release, but these instructions can be applied on many other Alfresco 6 releases.

 

This post includes sample configuration for every point, but you can check detailed and running configuration at 201804-EA Docker template

 

Images

Alfresco 6 provides several Docker Images to build every container for different services:

 

Persistent storage

Docker relies on external storage to persist information. When running an Alfresco server, repository, database and search containers are storing data that needs to be persisted.

A volumes tag must be added in docker-compose.yml file to every container definition to map local storage from your server with logical storage inside the container.

alfresco:
    volumes:
        - alf-repo-data:/usr/local/tomcat/alf_data
postgres:
    volumes:
        - postgres-data:/var/lib/postgresql/data
solr6:
    volumes:
        - solr-data:/opt/alfresco-search-services/data

volumes:
    alf-repo-data:
        external: true
    postgres-data:
        external: true
    solr-data:
        external: true

This code is using named volumes. In case they didn't exists, they can be created by using following shell lines:

$ docker volume create alf-repo-data
$ docker volume create postgres-data
$ docker volume create solr-data

Once this configuration is applied, your data will survive any Docker or Server re-starting.

 

Ports configuration

Docker uses internal ports for containers and it exposes to the server a mapping of these ports. In order to configure Alfresco protocols, ports exposition needs to be declared in Alfresco Repository Dockerfile...

EXPOSE 2121 1143 2525 1445 1137/udp 1138/udp 1139

... and mapping needs to be declared in docker-compose.yml

alfresco:
ports:
- 21:2121      # FTP port
- 25:2525      # SMTP port
- 143:1143     # IMAP port
- 445:1145     # CIFS
- 137:1137/udp # CIFS
- 138:1138/udp # CIFS
- 139:1139     # CIFS

It's also required to open these ports in the firewall of the operative system hosting Docker. 

Once this configuration is applied, your Alfresco server will be accessed by FTP, SMTP, IMAP and CIFS.

 

Web applications ports (AJP 8009 for Alfresco, AJP 8009 for Share and HTTP 8983 for Solr) must be also exposed to configure the Proxy at httpd container.

ProxyPass "/share" "ajp://share:8009/share"
ProxyPassReverse "/share" "ajp://share:8009/share"

ProxyPass "/solr" "http://solr6:8983/solr"
ProxyPassReverse "/solr" "http://solr6:8983/solr"   

ProxyPass "/alfresco" "ajp://alfresco:8009/alfresco"
ProxyPassReverse "/alfresco" "ajp://alfresco:8009/alfresco"

It can be used any other Web Container (as NGINX) to provide such configuration.

Once this configuration is applied, your Alfresco server will be accessed by using the same HTTP Port. In the next point the use of port 443 for HTTPs is detailed.

 

Configuring SSL Certificates

To provide real SSL Certificates, assets folder can be filled with working files:

  • CA.pem - CA Certificate Path
  • server.crt - Certificate File
  • server.key - Certificate Key File

Otherwise, it can be configured an external Docker volume to hold these certificates. 

Listen 443
<VirtualHost *:443>
ServerName alfresco.keensoft.es
SSLEngine on
SSLCertificateFile /usr/local/apache2/conf/server.crt
SSLCertificateKeyFile /usr/local/apache2/conf/server.key
SSLCACertificatePath /etc/pki/tls/certs/
SSLOptions +StdEnvVars +ExportCertData
</VirtualHost>

Once this configuration is applied, your Alfresco server will be accessed by HTTPs.

 

Adding modules

Folders to hold AMP or JAR modules has been provided.

alfresco/target/amps
alfresco/target/jars
share/target/amps_share
share/target/jars

Every addon copied into this folders will be deployed in the container.

If further configuration is required in alfresco-global.properties, Dockerfile can be modified to add pairs of property=value blocks

# Add services configuration to alfresco-global.properties
RUN echo -e '\n\
property=value\n\
\n\
' >> /usr/local/tomcat/shared/classes/alfresco-global.properties

Once this configuration is applied, your Alfresco server will provide features from installed modules.

 

Resources

Filter Blog

By date: By tag: