I have an mydocument.adoc document including a link to the pdf version of itself,
How to not include it in the pdf itself, (generated using asciidoctor-pdf)
... still including it when generating the html-5 version, using asciidoctor ?
// tag::pdflink[]
link:mydocument.pdf[pdf version,window=_blank]
// end::pdflink[]
To conditionally exclude (or include) content, you need to use conditionals.
When you run asciidoctor, the default converter (aka the "backend") is html5. You can wrap the content you want to exclude in a conditional that checks the intrinsic backend attribute:
ifeval::["{backend}" == "html5"]
link:mydocument.pdf[pdf version,window=_blank]
endif::[]
For any other backend, such as the pdf backend, that link won't be included.
See intrinsic attributes for other attributes that asciidoctor sets automatically for you. Any of them can be used in conditionals.
Related
I want to dynamically display a certain server status in an asciidoc (rendered in gitlab)
Something like
:status-server-1: 1
ifeval::[{status-server-1} == 1]
image::green_dot.png[green_dot,20,20]
endif::[]
Now how to dynamically set the attribute?
Is there a way the change the attribute with javascript or similar?
asciidoctor doesn't process JavaScript. It transforms Asciidoc markup to HTML (or other formats). JavaScript only comes into play when the resulting HTML is loaded into a browser.
It would be possible to run a JavaScript program before you run asciidoctor to determine the server status and set an environment variable that could then be used during asciidoctor processing. For example:
STATUS=`node status.js`; asciidoctor -a server_status="$STATUS" <file.adoc>
A different approach would be to use Docinfo files to add custom JS or CSS. Custom JS would allow you to perform an XHR request to discover the current server status and then adjust the classes/styles/images needed to reflect that status.
I want to have a template variable pre-processed in a markdown doc.
I tried converting the filename to file.html.md.eco but it just comes out as plain text - ie the markdown plugin doesn't seem to get applied.
The file just as html.md renders fine.
Is it needed to add the plugins to the docpad.coffee to make sure they're applied when using multiple passes?
the FAQ states how to use multiple processors
http://docpad.org/docs/faq
... Alternatively, we can get pretty inventive and do something like this: .html.md.eco which means process this with Eco, then Markdown and finally render it as HTML.
I am trying to integrate CKEditor into an internal PHP application, where in the past I was just pasting my HTML into a textarea field in a form.
This HTML that I am submitting in the form is for a custom template system that uses custom tags. These custom tags would then be replaced with real data by my backend. For example, an invoice would have the custom tag <%INVOICE#%>, which my backend would replace with the correct invoice number.
When using CKEditor, these types of tags are being converted into htmlentities such as <%INVOICE#>, which breaks my string replacement on the backend.
Is there a way to make CKEditor recognize tags that are in the format <%*%> and not convert them in any way?
The simplest way to protect those tags against modifications would be to use config.protectedSource. With Show Protected plugin (3rd party addon), you could even see the protected code in wysiwyg area.
A more user friendly solution would be to adopt the widget-based Placeholder plugin to recognize the syntax you use for custom tags. This plugin is just a proof of concept solution, so you can improve it in any way you like. E.g. by offering a select element to the end user with the list of valid placeholders instead of asking to type them manually.
Widgets are powerful, which means that it is technically possible to write even a plugin that returns <%INVOICE#%> in source code, but shows the real invoice number in wysiwyg area.
Dojo custom widgets can be internationalized via the _templated mixin following the steps outlined here and here. Then placeholders within the widget template like this: ${i18n.username} are automatically replaced with the appropriate language translation.
What is the simplest way to do similar nls language substitution outside of a widget? Ideally, I would like to add an attribute to a tag to have all the placeholders within substituted, including nested tags. Is there some type of container widget that already does this?
Or does Dojo development assume everything will be in a (custom) widget? I need to localize already existing code which doesn't use widgets.
The best solutions I have found so far are:
Using dojox.mobile.i18n, which is a "a thin wrapper around dojo.i18n, and has ability to replace strings, such as CDATA or attribute values, in dojo markup." However I'm afraid this is limited to a certain subset of mobile tags/widgets.
Disabling automatic parsing and manually searching/replacing the appropriate text before explicitly calling the parser in dojo.addOnLoad().
I assumed that the notation in the external html is ${i18n.username}.This will find any node that has class="i18nReplace" and replace the innerHTML of the node. I didn't test any of this, but I hope you can use it as a starting point.
dojo.require("dojo.i18n");
dojo.require("dojo.query");
dojo.requireLocalization("myI18n", "myI18N"); // This will need to be modified to get your i18n files
dojo.addOnLoad(function() {
var i18n = dojo.i18n.getLocalization("myI18n", "myI18N");
dojo.query(".i18nReplace").forEach(function(node, index, arr){
node.innerHTML = dojo.replace(node.innerHTML, { i18n: i18n } );
// blindly doing this, does not support nested tags.
// you could add conditional logic to check for children
// and if they exist separately process them, otherwise
// replace the html.
});
});
Is there a way to use a different styles, or redefine a style, based on a report parameter locale? I need to modify font sizes for certain languages.
I have implemented this in the past using external style templates. There is a sample on jasperforge that illustrates how to do this.
Once you've moved your styles to external templates, you can create locale specific templates. The templating mechanism allows you to inherit from and override specific styles, so the locale specific versions don't get overly bloated. The example I linked above includes inheriting from and overriding base styles.
In your reports, you can then load the appropriate template at render time.
One easy way to do this is:
provide the path to the template that you want to use as a parameter
to the report
include a template tag in the jrxml file that references the
parameter:
<template><![CDATA[$P{TEMPLATE_PATH}]]></template>
Then, in the code that renders the report, just set the TEMPLATE_PATH parameter appropriately for the report locale.
Again, the linked documentation mentions how to do this.