With the new programm option --logger you can define your own location of log.xml.

See here for more information.

Using comet_pdf, the function frame::image_rotate always uses [0, 0] as the center point of the rotation.

The problem is solved now.

The Python function CDocument.createPages does not interpret the 'index' correctly and crashed when the parameter has a value of 0.

The problem has been fixed.

The following improvements have been made to the Python integration:

New functions:

• link.getAtEdge

Breaking changes:

• link.collect: Parameter edge has been removed (it was incompatible with other parameters)
• link.collect: Parameter calcCoords new defaults to True
• link.collect: Parameter document has been removed
• link.collect: Parameter pages has been removed
• link.collect: Parameter frames has been removed
• link.collect: Parameter source has been added, consolidating other parameters

comet_pdf now also supports the PDFX/4 compliance. See here for more information.

When comparing comet Python types to intrinsic types like None, etc.. it is possible that a crash occurs.

This is fixed now.

I have an <in> tag with the setting i_rotate_prio 0, i_rotate 180.0, i_final_align fitframe. Unfortunately, the image remains invisible - apparently the XY position does not match the rotation and the image falls out of the frames clipping area.

This problem is solved now.

I have an <in> tag with the setting i_final_align fitframe. If I understand that correctly, this should adjust the inline frame to the image size. At least that is how it is done in InDesign. In comet_pdf, however, the inline frame unfortunately retains its original size.

This problem is solved now.

When the printer marks are shown in the resulting PDF, unfortunately the media, bleed and trim boxes are still wrong.

Hopefully this is correct now. In any case, the information corresponds to what InDesign produces with the same PDF preset.

Due to case 3068648 (see below), a large number of documents are no longer updated. Is there a way to fix these documents?

Yes, the missing <w2:> is now added automatically when reading in the W2ML. Old documents can be updated again with this fix.

I have a text frame with only one placeholder. If I export this text into string, the closing <w2:> is missing at the end of the string:

frame::gettext (fr, str, 0, -1, kExportW2);

The main problem here is that this function is apparently also used in the autosave mode of comet_pdf - the closing tags are also missing in the autosaved W2MLs. Since these placeholders are invalid then, they can no longer be updated by a later update (e.g. with linklist::load).

This bug has been fixed.

Inlines at position 0 in the text frame are imported incorrectly by InDesign when importing from W2ML. Here is a screenshot:

FXD

I have a text with an inline frame at the end. This text was saved by comet_pdf into a W2ML (--autosave). When I now open the generated W2ML in InDesign, the inline frame is missing. If I add at least one letter behind the inline, the inline frame also appears in InDesign.

The problem is solved now.

In comet_pdf the function image::set_alpha_channel does not seem to work. I always get the error 1286 (wrongAlphaChannelIndexErr).

FXD

The --autosave option of comet_pdf doesn't write any properties to the basic paragraph style [No paragraph style]. If such a W2ML is opened again, problems occur when displaying text. In my case, the text is displayed, but unfortunately with a color tint of 0 - i.e. invisible.

If the base style contains no further information, the following settings are set automatically (and then written later):

font    = "Minion Pro"
style   = "Regular"
size    = "12.0"
color   = "Black"
tint    = "-1.0"

Unfortunately, tables are only inserted at the end of section in the Accessibility Gtructure of a PDF-UA (/GenerateStructure in PDF preset) and not where they appear in the text. Here's a screenshot:

This is fixed now:

Unfortunately, the Python method CPageItem.moveTo does not move the frame to the specified page.

The table::create function apparently does not set the row height correctly in comet_pdf. In addition to the incorrect row heights, the cell contents are also displayed at incorrect Y positions. The screenshot shows a 2x5 table with a row height and column width of 30.0pt each:

Setting the row height to the negative desired height will solve the problem now. For more information see here.

When I call table::create with a given number of rows and some headers and footers, InDesign creates a table with the specified number of rows PLUS the headers and footers. In comet_pdf, on the other hand, a table with TOTAL rows is created, of which the specified number are header or footer rows.

FXD

The Template Behaviour setting 'New Page' does not work for comet_pdf.

FXD

In the Layout Rule "Set Frame Size", the size 0 (or empty) can be used to leave the frame size unchanged in this dimension. Unfortunately, the frame is actually set to size 0 in this dimension instead.

FXD

Case 2987276 (PDF cannot be created if printer marks are to be output) describes that it is not possible to use Printer Marks and Accessibility Structure at the same time. That's okay, we don't need both at the same time. But if both are activated, couldn't accessibility be switched off instead of the printer marks? If you want to see the printer marks, it's because you want to SEE something, so reading probably is of secondary importance in this case, isn't it?

That's probably true. So, if the printer marks AND accessibility structure are both activated in the PDF preset, the accessibility structure is switched off now by default.

Since one of the last releases the printer marks in the PDF not shown anymore.

This is an unexpected side effect of the fix from Case 2941874 (Wrong bleed settings). By adjusting the bleed boxes, the printer's marks fall out of the visible page areas.

The complete call to comet_pdf is written to the log file. That's great, I can simply copy/paste the command into the terminal and execute it. But if a parameter contains spaces, it does not work.

Here's an example:

--scriptout /Users/Paul/Desktop/My Results

We now enclose all parameter in double quotes. This solves the problem.

--scriptout "/Users/Paul/Desktop/My Results"

Can you guys check out why the "auto-generated date" time stamp on this data sheet looks odd?

The PDF shows 5ay 13, 2024 for a MMMM,y d yyyy formatted datetime variable.

This is fixed.

If printer marks are to be output in the PDF, comet_pdf cancels the creation of the PDF with the following error:

PDFlib exception occurred : [17020]
# PDF_moveto
# Element type Art (id 1) cannot contain content items, 
# but only other structure elements
# Removing invalid result '/Users/paul/Desktop/bbb.pdf'

This error has been occurring since v4.3 R34458. Previously it worked without any problems.

In the release mentioned above, we have started to insert so-called Acesibility tags (PDF/UA) into our PDFs. (/GenerateStructure in the PDF presets). The error only occurs if some printer marks are activated AND /GenerateStructure ist set to true.

To avoid the error, we now ignore the printer tags if /GenerateStructure ist set to true.The following warning in shown then:

Cannot create printer marks for Accessible PDFs (PDF/UA). Printer marks ignored. To disable PDF/UA please set '/GenerateStructure false' in your pdf preset.

The priint:comet InDesign^® plug-ins and comet_pdf are now supporting the HTML and PDF Export Tags (H, H1-H6, P, ...) when reading and writing W2ML files.

With an automatic (bicubic) recalculation of the contained images the PDFs from comet_pdf can be significantly reduced in file size. See here for more information.

Apparently the trim and bleed boxes of the generated PDF do not match the settings from the PDF preset (joboptions). Everything is correct on single pages, But on double pages there are a few anomalies:

• Left pages: The trim box appears to have been moved to the bleed. It starts at the same point as the left bleed and has the correct width. It therefore ends in the middle of the final format.
• Right pages: The trimbox looks correct. But Bleedbox has no bleed on the inside edge

This has been fixed now hopefully.

If I call frame::color_cmyk with the color values 0.0, 0.0, 0.0, 1.0 (Black), I still always get white as the frame color.

This bug is fixed.

The following improvements have been made to the Python integration:

New functions:

• CDocument.getID
• CDocument.setID

Unfortunately, server::load_placeholder_str does not recognize the placeholder's Function Variables using comet_pdf.

This bug is fixed now.

comet_pdf supports bullet and numbered lists and it also supports paragraph rulers. But you can't have both together, can you?

Paragraph rulers are now supported in lists too by comet_pdf.

The documentation says that I can set a small selection of text formatting without using TaggedText: This is actually quite pretty and essentially works. But apparently the tags for font and font color do not work in comet_pdf.

This now also works in comet_pdf.

But please note, however: The text attributes cSkew and cCharRotate are not supported by comet_pdf and the shortcuts of the same name will therefore continue to have no effect.

The Python function CTextModel.setParaStyle does not working as expected in comet_pdf.

This is fixed.

The following improvements have been made to the Python integration:

• The following functions now additionally accept tuple[int, int, int, str] for the recordID parameter(s):
  • placeholder.link
  • placeholder.load
  • placeholder.store
  • CFrame.link
  • CFrame.load
  • CFrame.store
• placeholder.link parameter length now has a default of -1 to prevent confusion when loading text placeholders
• placeholder.load parameter start now has a default of -1 (Load all placeholders)
• runCScript has a new parameter logExecution (default False) to disable logging about the script run (execution time, script ID etc...)

• run_python parameter flags can now be used to disable logging about the script run (execution time, script ID etc...)

When executing file::download_webimages, incorrect log outputs are generated:

• In a test with 29 (different) URLs, there were 29 different paths in the resulting IDTypeList. I was also able to find 29 different files there.
• However, not all 29 different URLs are listed in the logs; some are repeated and others are not mentioned at all. Are the files mentioned several times actually downloaded or is this perhaps more a behavior when writing the log lines?
• I also noticed lines in the logs with a special character and a truncated URL at the beginning of the line. Do these lines mean something specific? In one file, the end of the file name was chopped off. If I remove / correct the corresponding lines, I get the correct number of files again. So it only seems to affect the logs.

These problems arise because 'many' processes (here 29) are writing into one log file more or less at the same time. We removed the logs for this function.

We have also removed the 'Download file' terminal messages from comet_pdf.

For some time now, the log has contained a very large number of messages for loading fonts. Could a few of them be removed again?

The log is not actually the subject of any discussions and is used solely for evaluation by the developers/programmers. But in this case, the messages were actually intended to solve a developers problem and we have now removed these lines again.

The document::select function does not exist for comet_pdf, does it?

We have now also implemented this function for comet_pdf.

If my text contains softs hyphenations (U+00AD), the paragraph delimiter no longer work properly in comet_pdf.

This is fixed.

Would it be possible to have text wraps for rotated frames as well? At the moment I get an error message:

Frame NNN has text wraps with unsupported rotations and/or skews.

This is a small mathematical problem that requires a few semesters of math study to solve. Text wraps of rotated frames are now supported by comet_pdf :-)

The new page::set_size function can be used to change page sizes in both InDesign® and comet_pdf.

Bitte lesen Sie vor Verwendung unbedingt die Hinweise zur Funktion!

This was a special requirement from a customer that was included in the standard by mistake. The problem is solved now: If one paragraph of the given text model has turned off the hyphenation, Quadruple letters are not hyphenated in the whole text anymore.

Please take care: Since quadruple hyphenation is not an InDesign^® feature (and we don't have a TaggedText tag for it therefore), we can't limit the feature to paragraphs only but only to the whole text.

If I have a text with very long words, the hyphenation character (-) is shown even if hyphenation is switched off. This does not happen in table cells.

The problem is solved now.

I try to define a spot color using document.createSwatchCMYK. But the created color is always a process color.

FXD

I use a script to create a text frame with comet.frame.createTextFrame. This works without errors. Then I would like to insert a text with frame.setText into the new created frame. But then I get the error message 'Not a text frame'.

FXD

Using Linux 22.04 comet_pdf always aborts with PDFlib error 1118 (Wrong font -1 in PDF_info_font). However, I am sure that all fonts are defined.

To create paragraph spacing and inlines, comet_pdf requires a font in the background. This is Arial for Mac and Windows. On Linux /usr/share/fonts/truetype/tlwg/Garuda.ttf is used for that. Unfortunately, this font is not always installed in Linux 22.04. We have therefore added the Ubuntu-Regular.ttf font to the installation folder. If the above-mentioned background font is not found, Ubuntu-Regular.ttf next to comet_pdf is used instead.

However, comet_pdf is not released for Linux 22.04! Then bugs like this can happen :-)

In circles and ovals, the text is always split in the middle. It looks a bit like the frame has two columns - but the gap widens towards the bottom.

FXD

The function Python CFrame.hasOverset always raises an error in comet_pdf.

FXD

The error only occurs using the Linux version of comet_pdf: Layout Rules that contain if-else-end constructions are not executed correctly by comet_pdf under Linux. It seems that rules are executed even if the if-condition is false. In addition, the message that the closing end cannot be found always appears in the log.

# ELSE/END not found for condition 'Frame is Empty' (list entry 0)

The bug is fixed now.

I have just tried to remove a page with a Python script. The script is a build script and the function is called after all products are already established.

page = comet.gDocument.getPages()[pagenum]
page.remove()

When the remove method is called, rendering is aborted with an error message.

Yes, the corresponding internal method for page.remove was not yet implemented for comet_pdf. It will be fixed in the next release.

No Functional Changes

See History of v4.3

See History of v4.3

See History of v4.3

No Functional Changes

This is the first official release of priint:comet PDF Renderer v.4.3.