PdfpTable vs. Table (vs. SimpleTable?) - itext

I am writing code that generates both PDF and RTF documents, depending on the user's selection. The information in both documents is the same.
Until now, we were using classes like Table, Cell, HeaderFooter, etc., which are rendered into the correct form by the documentwriter (either PdfWriter or RtfWriter2).
However, the further I get into trying to make changes (mostly because the upgrade to iText 2.1 left the spacing a little quirky), the more I'm being told to "use PdfpTable", or "Use pageEvents to set headers". It seems like a lot of the generic classes are being deprecated.
I am thinking of revamping the code to separate out the table creations for PDF and RTF. However, all the iText tutorial stuff seems to actually recommend using Table in an instance where both PDF and RTF documents are needed.
Additionally, it appears that while there is a PdfpTable class, there is nothing similar for RTF, so I would be using Table anyway, which would leave me vulnerable to all the quirks that come along with the now unsupported Table class.
Basically, what are the benefits/downsides of separating the code into two sections -- one to create PDF documents, and one to create the same documents in an RTF format, if that was selected? And where does SimpleTable come in to all of this? Will it give me the flexibility that I need?
Thanks!

From the book iText In Action, end of chapter 6:
If you look at the iText API, you’ll also find some other table classes. com.lowagie.text.Table is the original table class; it dates from the early iText days. It uses class com.lowagie.text.pdf.PdfTable internally to render a table to PDF (don’t confuse this class with PdfPTable).
There’s also the newer SimpleTable class, which tries to form a link between
PdfPTable and Table. It’s able to translate itself to a PdfPTable if you add it to a
document that writes PDF or to a Table if you’re producing HTML or RTF. [...]
The major disadvantage of the Table class is that it’s no longer supported. Different
people have fixed most of the known issues, but today not a single person
understands if and how all the Table-methods work. If you decide to use this class,
you’re more or less on your own, and you’ll encounter lots of quirky layout issues
based on historical design decisions. However, this doesn’t mean you can’t make
good use of the Table class.
Advantages of the Table class
With the Table class, you can generate a table structure that can be rendered in
PDF, RTF, and HTML. If you compare the results, you’ll see there are small differences
in the way the table is rendered. This is normal; not every table feature is
supported in every document format.
You can generate a table in PDF, HTML, or RTF using the same code.
You can set padding and spacing the way it’s done in HTML.
You can use the row span without having to resort to nested table.
You can change the number of columns even after you’ve added cells.
You can add cells at specific positions (the number of rows is augmented
dynamically).
You can delete a column before adding the table to the document.
You can let iText add the Table as if it was a PdfPTable.
You get a PdfPTable object based on the Table object.
As opposed to PdfPTable, you can add cells to a Table in a random order, and add
or delete columns if needed. You can even translate a Table to a PdfPTable if you
didn’t use setRowspan().
There’s also the SimpleTable, class, which is a simplified version of (PdfP)-Table. When adding a SimpleTable to a PDF document, iText first attempts to add
the table as a PdfPTable; if this fails, it’s added as a Table. When adding a SimpleTable to an RTF or HTML document, it’s added as a Table. SimpleTable differs
from the Table and PdfPTable in the sense that it reintroduces the concept of rows.
This can be handy if you’re parsing an XML file that has a table-row-cell structure.
If the tag corresponding with the rows has attributes, you don’t have to define this
property for each cell in the row separately; you can set the property for the entire
row at once.
Summary
PdfPTable should be your first choice; but depending on the requirements defined for your project, there can be good reasons to opt for Table or SimpleTable.

Related

Constrain a column across tables

I'm using Postgres to store formulae and elements of formulae across two tables. Basically, you have something like:
Elements Table
symbol
content
pi
3.1.45
lune
42
Formula Table
symbol
content
area
pi*r^2
rugsize
area*lune
So, formulae can use elements but also other formulae in their content field. For this reason (and for general reduction of confusion) I would like to make symbol unique across both tables.
I can, of course, in the code that's doing the insertion, look up the entries before adding them and refuse to add a duplicate symbol. (I probably will do this, but I don't want the database reliant on that.) I could also require a tag within the formula table to specify when it's using another formula:
symbol
content
rugsize
f(area)*lune
I'm not crazy about that since it puts a burden on the user to remember that, or on the coder to secretly add and remove the "f()".
Everything I found on Stack and elsewhere went the other way: Forcing a column value to be present in another table, except for one suggestion that the unique items be kept in a separate table.
symbol
area
lune
pi
rugsize
And then...actually, I'm still not sure how that would work at the DB level.
So, is there a way to do this with constraints or foreign keys, or must I write a trigger for each table to look into the other table?
Addition: I've simplified here greatly but the elements table is much more complex than I'm showing and has little in common with the formulae table.
Edited to add the above addition and to try to fix the one-column "symbol" table which looks fine in the editing preview but does not format correctly on the actual page.

Create a dynamic table in a PDF Form programmatically

I need to generate a pdf based on a template form.
In that form there is a table that needs to be populated.
Since the table can have a unknown amount of rows, what I was thinking was drawing the table and then adding it to a space on the form.
As in, the form would have a acrofield to receive the table itself.
I already managed to create the table and put it inside a pdf, but I'm having issues puting that table into a acrofield.
As far as I can understand a form only appears to accept these: button, text, choice, or signature.
I'm using Apache pdfbox and easyTable to manipulate the form and create the table.
Is it possible what I want to do? If so, where can I find more information about this topic?
Edit: This answer seems to be what I want to do.

TYPO3 - store custom content element data in own database table

I want to create custom content elements. I know how this works basically. But I asking myself, if there is a way to store the configuration data of this elements in a decent database table?
I only know the way to extend the tt_content table and store my data there. But with a bigger amount of elements and fields the tt_content would be become bigger and bigger too. I would like to prevent this.
And just before you ask: I don't want to use FluidTYPO3. ;) I just would like to do it with basic TYPO3 functionality.
Don‘t know if there is a nicer way, but maybe you can create your elements with no field definition but with IRRE and min:1 and max:1 - but this is not really a nice way.
The better way is to reuse the fields given in tt_content as often as possible and only add more fields if really needed.
Maybe you should have a look on EXT:mask and EXT:mask_export - those two are very powerful tools to create custom content elements (EXT:mask) and export them as an own extension (EXT:mask_export) so there is no need for these two extensions in production but only in development.
As you create a content element you will always need to use the database table tt_content. Of course it makes sense to use relations to custom records, e.g. if you create elements like tabs, accordions, ...
What you can do is to reuse existing columns as there are - as you said - a lot of those. So reuse fields like header, bodytext, image, ... Take a look at /sysext/frontend/Configuration/TCA/tt_content.php. The benefits are
a bit smaller table which is most of the time not really relevant to performance
well designed fields including a label whith translations into all languages
You can also reuse a field and its configuration and override it with overrideChildTca. See https://docs.typo3.org/typo3cms/TCAReference/ColumnsConfig/Properties/InlineOverrideChildTCa.html?highlight=overridechildtca in the docs.
I recommend you to have a look at the typo3 extension mask. You can create custom contents and map existing tt_content fields to your new elements. It makes sense to reuse the header, bodytext, media, image fields because the backend preview will adopt automatically.
I used it recently and it works really nice! Here is some resource to jump in (only german)
If you do not need to have indexes on your new fields it is not a big problem to blow up tt_content with new fields. It does not impact the performance so much.
If you need to have new 1:N relations from your content to some child-record (accordion, team-listing, etc), simply add them as inline elements (IRRE) and add the field to your types-string.
If you need to have a new kind of data, that should be filterable, sortable and so on, you should create a new type of record with its own table structure and use extbase plugins to display that data.
As long as you simply need custom contents, you are fine with extending/remapping tt_content.
You can use hooks for this.
In your ext_localconf.php:
$GLOBALS ['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_tcemain.php']['processDatamapClass'][] = \Namespace\Hooks\Classname::class;
And in Classes/Hooks/Classname:
<?php
namespace Namespace\Hooks;
use TYPO3\CMS\Core\SingletonInterface;
use TYPO3\CMS\Core\DataHandling\DataHandler;
class Classname implements SingletonInterface {
public function processDatamap_beforeStart(&$dataHandler) {
$datamap = &$dataHandler->datamap;
}
}
Here you have to modify the $datamap to your needs.
Documentation is here: https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/Typo3CoreEngine/Database/Index.html
Kind regards
It is explained here https://learn-typo3.com/blog/news-detail/how-to-create-custom-content-elements-on-typo3, however I prefer extending and reusing tt_content fields.

TinyMCE table column properties

TinyMCE editor seems to lack the capability of applying table cell properties to the whole table column (which would be much less trivial problem, than applying to the whole row - that functionality is there).
Is there a working soultion for that (patch, plugin..)?

Selecting different columns in SWT Table, using JFace TableViewer

I have a 2-column SWT Table that uses TableViewer. Trouble is that I can only select (and edit) cells in the first column -- clicking on the second column does nothing.
I read from somewhere (lost the link) that there's no easy way to get such functionality (!) -- you're supposed to mess around with several extra concepts if you want to select (and edit) different columns in your table.
This snippet
(http://www.goneeded.com/snippet/eclipse/JFace/Viewers/Snippet035TableCursorCellHighlighter.html)
seems to be relevant, but it's not clear which part of it is necessary and it has depenendencies to other snippets. I tried to get it working but it did nothing.
Seems that new table editing and cell-selecting features were added in Eclipse 3.3 -- is there a tutorial or smth available on how to use them? The snippets are too cryptic for me.
You should be able to edit and select cells independently. You might have the SWT.FULL_SELECTION style bit set on the Table constructor. That forces every selection to span the whole row instead of a single cell.
I'd check out this tutorial for more on TableViewers:
http://www.eclipse.org/articles/Article-Table-viewer/table_viewer.html