I put two different images into the gridelements appearances of the standard language and the foreign language.
The images references are stored in the tables "sys-file" and "sys-file-reference". The image of the foreign language is stored with the uid of the translated CE instead with the uid of the standard CE AND the correct data in the field sys-language-uid?
So using an image e.g. for different backgrounds in the two languages is not possible, is it?
Related
I am tring to build an accessible for the hard of seeing pdf file using JasperReports java framework
There is an option of adding accessable tags to tables, but it looks like the reading is done from left to right
This is not what I need, since this is a hebrew (rtl language) pdf
I see that there is support for RTL crosstab elements in JasperReport, but I didn't see any for tables
What would you suggest as the best way to have the accessable rtl support on pdf tables?
Tried to use chat gpt, unfortunately it gave me all kind of properies to use that were not recognized by Jasper
I tried to reorder the tables rows after having jasper calculate there positions, but that caused some of the rows not to be read properly
I solved this by overriding the exportFrame(JRPrintFrame frame) and exportElements(Collection elements) methods in JRPdfExporter of the JasperReports framework
In exportFrame(JRPrintFrame frame) I chacked if we are in table using the "net.sf.jasperreports.export.accessibility.tag" property
if so I marked this
In the exportElements(Collection elements) method I check if we are in a table and if so I swapped the text, x and width values of the left and right elements (for example if we have 4 elements, than I swap element at index 0 with that in index 3 and element at index 1 with the element at index 2
by doing this the order of the tags (witch dictates the read aloud order) is different then the drawing order (witch dictates how it is seen in the pdf)
We have changed the primary language for our site https://staging.venicexplorer.net from English to Italian. But the problem is it is showing English text when we selected Italian and vice versa. We are now altering the languages of the content. But this is a very time consuming job. Can anyone please tell me whether there is any shortcut method?
Thanks
Prasun
Here are some hints for updating the language of content and pages in the database:
Content
The language of a content element (table tt_content) is in the field sys_language_uid. Default language is always 0, "all languages" is -1.
Each translated record (sys_language_uid NOT IN (0,1)) can (aka "connected mode") have a link to its default language counterpart. This is set in the field l10n_parent.
Pages
First of all for TYPO3v9 this depends on the feature toggle unifiedPageTranslationHandling. I will assume that your instance is already fully migrated to not use pages_language_overlay any more.
The same rules as for tt_content apply: sys_language_uid is the language, l10n_parent the default language record.
Other records
The same applies to all other translated records in TYPO3 or its extensions.
Technically, these fields are defined for each table in TCA in [ctrl][languageField] and [ctrl][transOrigPointerField] but sys_language_uid and l10n_parent are used mostly.
Notice
This is not an exhaustive list. There are fields that are only set in the default language (e.g. access restrictions). Make a backup first! But that should cover most bases.
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.
I had to import a few posts from one TYPO3 site into another, which lead into some exploring of the DB structure. A specific question arose:
In localised content elements (tt_content entries with sys_language_uid = 1), the fields t3_origuid and l18n_parent are redundantly filled. l18n_parent is required for the backend localisation view to work.
Do they always have the same value? Or is there a use case where the values of the fields can differ?
l10n_parent / l18n_parent
The field configured in TCA as transOrigPointerField (usually l10n_parent or l18n_parent) is used for localization.
It always contains an id of the record in the default language (even if the record was translated from a record in non-default language), see https://docs.typo3.org/typo3cms/TCAReference/singlehtml/#transorigpointerfield
t3_origuid
The field configured in TCA as origUid (usually t3_origuid) is filled when record is copied or translated, and contains an id of the source record, see https://docs.typo3.org/typo3cms/TCAReference/singlehtml/#origuid
The fields will have the same value in some cases (e.g. translating a record from default language), but in other will have different value. E.g. when copying a record on the same page t3_origuid will be different than the l10n_parent.
To allow localization it is required to have transOrigPointerField (l10n_parent). Having origUid (t3_origuid) field is not hard requirement but a good practice as as some additional features may require it to work. Especially in newer versions of TYPO3. For example the Translation Wizard is currently using t3_origuid field.
l10n_source (since TYPO3 8.6)
Since TYPO3 8.6 a new database field l10n_source for tt_content table has been introduced together with a new TCA ctrl configuration translationSource. The translationSource field contains an uid of the record used as a translation source, no matter whether the record was translated in the free or connected mode.
see more in the documentation on l10n_source field
Those fields can have different values.
t3_origuid is a generic field pointing to a record from which the current one was derived in some way. For example by copying or localizing it. Here is some documentation for it.
The field l18n_parent is reserved for localization purposes.
Just as a addition to Jost's post:
To determine which field you should use check the value of:
$TCA['tx_yourtable']['ctrl']['transOrigPointerField']
ie. for tt_content it's:
$TCA['tt_content']['ctrl']['transOrigPointerField'] = 'l18n_parent';
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.