What if images produced from PDFs within the timeline of LiveCycle need to all be the same size? PDFs that are the same size, dimension-wise, can turn out as images of different sizes after processing with the toImage activity. For example, two PDFs could be 8.5 x 11 inches in size. But one would convert to an image that is 1700 x 2200 pixels in size and the other would convert to an image that is 2550 x 3300 pixels in size.
Use the same DPI argument for each of the PDFs. The resulting images will not be an exact match with one another, however. In my test a variation of ten pixels or so could be seen as the result of differences in the areas of the PDF page that are converted to image. But PDFs that are the same dimensions before conversions result in images that are the same pixel height and width (or very close to it).
The documentation for the toImage operation of the Convert PDF service
CRXDE is the eclipsed-based tool used to to develop within the CQ and CRX repository. By default, only a few directories within the repository are visible. The content directory is not one of them. A setting in the repository must be change before it can be seen.
Go to /etc/crxde/profiles/default. There is a property, crxde:paths. This property is a list of String. Add /content to that list and restart CRXDE.
The Atom blog feed from CQ that is obtained by using the .feed suffix on a URL has exceptions within it. The output is an error witinh the feed.jsp or feedentry.jsp file and it contains the following:
Caused by: java.lang.IllegalStateException: output stream already obtained
What Can Be Done?
There is a structural supposition within CQ that the output of JSP pages will be HMTL. Because of that, <div> tags are generated for sections of content automatically. Writing these <div> tags causes writes to the output buffer that should not happen. Even if writing to the output buffer did not cause the exception, it would create bad Atom files with <div> tags sprinkled throughout in places they should not be. Changes need to be made to the JSP pages that handle the *.feed suffix. Those files can be found here:
/libs/foundation/components/page/feed.jsp /libs/foundation/components/page/feedentry.jsp /libs/collab/blog/components/page/feed.jsp /libs/collab/blog/components/page/feedentry.jsp
Within ALL feed oriented JSP files (*.feed.jsp, *.feedentry.jsp, etc) the following must be added:
// This bypasses the normal component handling with its automatic output of content
// This changes the tag used for blocking areas of content from "div" to "".
// When empty, a tag will not be written to create blocks of content.
These nodes are part of the foundation components for CQ. Make backups. And be aware that these components can be overwritten without warning in future updates. You will need to document well the changes that have been made in case problems arise later.
Greg Klebus suggested using WebDAV to mount repository directories on the file system. Doing this, he said, the end user has access to file system directories on which CQ can automatically run workflows.
A quick example of this is mounting the DAM directory as WebDAV. When content is added or changed within the DAM directory of CQ, a workflow process will run automatically.
These are the steps I go through for using WebDAV with Windows 7 to do that very thing.
I mount the CRX repository as a mapped drive within Windows 7 by right-clicking on the computer and selecting the Map Network Drive menu item. I pick the drive letter and, for my local installation, use the CRX WebDAV URL for my server .
Windows 7, out of the box, may not support WebDAV. To use WebDAV on a computer with Windows 7 you may need to install an update from Microsoft: Software Update for Web Folders . You may want to see if it works without this update. It is an old software update and only lists Windows 2003 and Vista specifically. For instructions on how to get Windows 7 64bit, specifically, to work with WebDAV go to .
Within CQ 5.4, you can set the permissions of a directory under /var/dam to allow read/write or write privileges for the end user. When they drop an image into this folder there is a workflow that explodes the image, generates thumbnails, and creates the dam:asset for that image. The result of the process can be seen in the /content/dam directory. For CQ 5.5, images placed into /content/dam and its sub-directories will trigger the workflow.