Our customer uses a TYPO3 9.5 LTS and complains about the fact that they always have to activate the "alt" tag in the TYPO3 backend to enter the text. We force our customer to do so to hit the W3C requirements.
So is there a way to activate the checkbox by default in the backend? Or may be to remove it at all and allow to prompt even an empty field there?
All images should have a (global) default entry for these fields(title, alt-text, description). Then you would see this default value and only if you want other values for this usage of the image you need to activate the field to edit.
If your editors only fill in the fields for each usage (probably always with the same data) they do additional work.
Show them how to edit the data in the file-manager (File List module):
Open the backend module FILE-> Filelist.
If you have not done yet: check [x] Extended view beyond the list of files and folders.
Then you will get more icons in this view which otherwise are ony available in the contextmenu.
The important icon is the pencil (edit button). it does not edit the content but the metadata of a file.
If you insist on SEO you probably have installed the extension filemetadata which adds some more information fields and scheduler tasks to extract data automatically.
So the amount of available fields to edit depends on the extensions you have installed, but the basic filds are availe by the TYPO3 core.
If your editors upload new files they should fill in these fields to have the information available with each usage. And only if there is a usage which needs other metadata your editors need to make this fields editable.
Related
So that the link can be used in some external applications, and users in that application can click the link and navigate to that specific location (text or area) in the pdf.
Is this possible?
There are several different URL # (fragment) constructs that were introduced by Adobe for use with their web browser PDf viewer plug-in. The current accessible list is at https://pdfobject.com/pdf/pdf_open_parameters_acro8.pdf
Many newer competing PDF enabled browsers may use similar, but there is no guarantee one URL.pdf#Fits all. Most will respect #page=number&zoom view or fit but it is very variable, thus you need to check each feature across browsers.
Important to switch off any PDF remember my view settings
For your previous request using Bookmarks can be unreliable (as can the comments ID) unless you are using Acrobat and can check the bookmark function. By far the more reliable may be the use of zoom at a scroll location so here using MS Edge:-
"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" file:///C:/Users/.../Desktop/CEI-PID-Sample-Rev4annotsC.pdf#zoom=300,200,200
I support SumatraPDF however its browser plug-in whilst still functional is way past EOL thus unsupported, it had a limited support for those fragments even though the CLI was recently extended for some Acrobat /Action commands.
However related to your desire the one single portable EXE can jump to well formed text blocks. Here I call "V 4508" in a fairly similar fashion
"C:\Program Files\SumatraPDF\SumatraPDF.exe" "C:\Users\WDAGUtilityAccount\Desktop\SandBox\apps\Graphics\CEI-PID-Sample-Rev4annotsC.pdf" -zoom 300 -search "V 4508"
And if I press A then the text will be highlighted for comments
It is possible in the moment of upload a content to a document library show the fields defined (of the document library)? At the moment, the only way that the user have to fill the fields is uploading the document first and then click edit to fill the fields.
Unfortunately there is no out-of-the box solution for this scenario. I agree that this would be useful, but currently you have to create a custom solution.
You will have to create a UI that displays the upload control (you can use the built-in Sense/Net plugin) and also the form fields. In the click event of a button, you have to first start and finish the upload, retrieve the new content id and than update the metadata fields - all this in JavaScript. This way users would not see the difference, for them this would be a single operation.
(in mid-term we plan to offer a built-in control that will make this possible, but we do not have a timeline for this feature)
My problem is that we have made an block that opens a page witha a mform on it. And we use the editor element to start the tinyMCE editor, on the page. But when we save the output, the images oploaded to the text field is only viewable to the admin (the person who uploaded it) and in the mdl_files it sets it to be a draft file. I have been through the documentation, and i might have lost the context on the new page, but im not sure.
In Moodle, files uploaded to a form (either to a filemanager element or a text editor) are stored in a temporary 'draft' area while the form is being edited.
This is so that the actual files are not changed until the form is submitted (e.g. if an admin changed the image embedded in some text, deleting the original, you do not want anyone viewing the page during the editing to see a broken image link).
When working with files embedded in a text editor in Moodle, you need to make sure you copy all existing files into the 'draft' area before you show the form, then copy the 'draft' images into the real area, after the form is submitted.
See https://docs.moodle.org/dev/Using_the_File_API_in_Moodle_forms#editor for details about how to do this.
Please also note that your plugin will also need a PLUGINTYPE_PLUGINNAME_pluginfile() function in its lib.php, in order to authenticate any file requests from the user's browser and return the file contents. See any of the core activities for examples of this (e.g. mod/data/lib.php - function data_pluginfile()).
I am creating a Smart/Fillable PDF using Acrobat Pro DC.
I created a word file with 250+ fields(in a tabular manner), exported to PDF and then in "Prepare form" options I added checkboxes, dropdowns and a couple of buttons and the form is ready. Now I want to add 50+ more fields into that PDF but if i follow the same procedure export to PDF and then "Prepare form" then i shall loose all the old validations and scripts I have written initially.
To overcome this scenario I tried a couple of things that didn't work for me:
Go to "Edit PDF" option and try editing PDF but that did not work as that option helps editing text and images but I have fields in a tabular format so in case if I want to add a table with N x N fields not possible
Tried to copy all elements including textbox,checkbox,dropdowns buttons etc but cannot copy all at once, tried then in a small group like 15-15 and that worked but still I had to reposition so not a feasible way
Tried to export the elements including textbox,checkbox,dropdowns buttons etc but Acrobat Pro DC doesn't help
Many other manipulative things but didn't help.
Please help me to overcome this problem.
Thanks in advance.
If you change the background of the form, you would first open the old version, and then replace the pages with the ones from the new version. This does not affect any form fields, so, only some repositioning may be necessary.
Then you go to the form edit mode (or use the Select Object Tool (single key accelerator R)) and you can select the fields you want to copy and either drag-copy if you are on the same page, copy/paste them, or duplicate them on other pages (via Context menu of the selected field in edit mode).
Another potentially important hint: deactivate Save as… optimizes for fast web view when working with forms.
I want to create a pdf form for two language (Chinese/English) UI, and there's a button(s) or somethings on the form for language switch, is there anyway can make it? and how to do?
thanks!
Thanks for all reply!
Actually I got a sample like this,
PDF Sample
there're two checkbox on the top-left of the form, one is for English UI, the other is Chinese, I just want to know how to make PDF like that sample? (and I don't see any layers on the sample...)
thx
mkl's comment (which he should turn into a full answer, really) already hinted at the option to use different page templates residing in the same file.
Another option you could explore is this:
put the two language versions into 2 different layers (or 'optional content groups' in PDF parlance)
make the visibility of the two layers toggeable
let the user activate that layer which he/she needs.
Layer activation can be handled through normal Acrobat Reader user interface elements.
The layer switching can be made accessible via a "button" on the PDF page too -- but that requires additional JavaScript to be embedded in the PDF (something many people are not particularly keen about).
As Kurt proposed, I make my comment on Frank's answer an answer in its own right:
Actually there is a pdf feature seldomly used nowerdays, page
templates. Thus, those two forms can reside in the same file in
different page templates, and based on some initially present buttons
("English version", ...) the desired form is spawned.
Unfortunately I don't know how to create page templates using some easy-to-use tool, I only came a cross them in the context of integrated PDF signatures (depending on the signature type, page template instantiation is a document change not breaking the signature) and tested them with low-level tools.
Essentially page templates are PDF objects just like page dictionaries of the normal pages, they are not XFA stuff. They merely are not referenced in the pages tree but instead in the name tree.
There is a JavaScript command which creates a visible page based on such a template --- I don't know which anymore; I may be able to find out when I'm back in office next week. This command would have to be bound to the inital language selection button in the file.
The problem will be in switching the static text - PDF does not allow this.
If I were you, I would split the document into two identical forms in the respective languages. You can use bookmarks and links on the first page to navigate to the right part of the document.
Note that it is possible to assign the same field names to the Enlgish/Chinese versions of your fields. This will make it easier to process the submitted form data because the process path would be independent of the chosen language. It will also simplify any JavaScript (validation, summing, etc.) you plan to add.