I would like to create a XPages form to print it out. I am not sure which is the best way to do this. I mean I need to create a panel or table or any other design elements then put all my staff in it?
I need advise:)
Regards
Cumhur Ata
Speak after me: browsers don't print.
If you need precision layout a browser is your worst enemy. Each one renders slightly different, so don't bother.
Your best bet is to create a PDF file for printing. There you have pixel-perfect rendering as you deem fit.
You can use iText, PDFBox or XSL:FO to generate PDF. There are code samples on OpenNTF or you read my blog entries about it.
Related
I use LibreOffice Writer and I want to insert an alternative text to a specific phrase in the document, how can I do it?
Example if we have an image in the document we can make double left click and add the alternative text like this:
Is it possible to make the same if we select a whole phrase of text? If yes how? And if No is there any other proposal?
The alternative text in 'word'/odt documents is actually intended as the 'alt' attribute in HTML (web) pages:
The alt attribute provides alternative information for an image if a
user for some reason cannot view it (because of slow connection, an
error in the src attribute, or if the user uses a screen reader).
(http://www.w3schools.com/tags/att_img_alt.asp)
It's only purpuse is thus to provide the user with information in case he/she can not view the image. Since having alternative text in case some text cannot be displayed is, well, silly, this 'alt' attribute is not defined for pieces of text. Alternatively, you could have a hyperlink pointing to nothing ("#"), which does provide a tooltip attribute.
What is it that you're intending to achieve anyway? It's not going to show up on any prints, which is the intended purpose of Writer... Footnotes (for prints) or Comments (for communication with co-editors) might suit you better.
I am trying to get my head around the UIMA architecture.
I would like to create a pipeline that starts with HTML markup. I need to strip this to plain text, so it can be processed by different annotators, like POS, chunking, entity detection, etc. However I would also like to keep track of which regions correspond to the original html tags, like links, paragraphs, em, etc. Basically I would like a final annotator that takes advantage of structural annotations (from html) and semantic annotations (from the other components), all at once.
So, I can imagine starting off with a component that strips the html markup and adds annotations to keep track of the tags I am interested in. Does such a component exist already? It seems like something a lot of people would want.
If I do have to create it from scratch, what kind of component is it? It's not just a straight annotator, because it needs to change the SOFA: it needs to replace the markup with plain text.
Or should I have it create a new view of the document, so we maintain a markup view and a plain text view of the document? This seems weird, considering I will never care about the markup view again. Also, how would I make sure the other annotators (which I won't be coding myself) operate on the plain text view of the document rather than the markup view?
Depending on the complexity of the markup, some people use Apache Tika, and some people use Boilerpipe.
Here is a blog post from someone who wanted to use Boilerpipe in UIMA but ran into a snag because he wanted to preserve offsets back to the HTML.
Here is the UIMA annotator that calls tika.
UIMA Ruta provides some analysis engines for this task. The HtmlAnnotator creates annotations in the html text for the different tags. The HtmlConverter is able to create a new view that contains only the text of the html, but with the corresponding annotations for the tags. There are some configuration parameters for handling linebreaks and so on. For further processing without sofa mappings in a pipeline, there is the ViewWriter that is able copy the new plain text view to the _initalView of a new file.
DISCLAIMER: I am a developer of UIMA Ruta
I am trying to make a print newspaper that is easily generated from my WordPress site. I am trying to design the print template for it, but in order to control specific pages, I need to use the #page rule.
I read this tutorial, which suggests methods like:
#page :left {
#top-left {
content: "Cascading Style Sheets";
}
}
But when I try this in Firefox 5 (and Chrome 14) print-preview or print, it does not print anything at the top-left. In fact, I can't seem to do anything within the #page rule.
Am I doing this wrong or is this a CSS3 feature that just hasn't been implemented yet?
Just after the preface, the tutorial states:
Web browsers are good at dealing with pixels on a screen, but not very good at printing. To print a full book we turned to Prince, a dedicated batch processor which converts XML to PDF by way of CSS. Prince supports the print-specific features of CSS2, as well as functionality proposed for CSS3.
So, the tutorial code isn't meant for use with a browser's print function in the first place.
In any case, as I said in my comment, I wouldn't count on any browser implementing this yet. Everyone's crazy about the stuff happening on screen like animations right now.
Tagsoup is interfering with input and formatting it incorrectly. For instance when we have the following markup
Text outside anchor
It is formatted as follows
Text outside anchor
This is a simple example but we have other issues as well. So we made tagsoup cleanup/formatting optional by adding an extra attribute to textarea control.
Here is the diff(https://github.com/binnyg/orbeon-forms/commit/044c29e32ce36e5b391abfc782ee44f0354bddd3).
Textarea would now look like this
<textarea skip-cleanmarkup="true" mediatype="text/html" />
Two questions
Is this the right approach?
If I provide a patch can it make it to orbeon codebase?
Thanks
BinnyG
Erik, Alex, et al
I think there are two questions here:
The first Concern is a question of Tag Soup and the clean up that happens OOTB: Empty tags are converted to singleton tags which when consumed/sent to the client browser as markup gets "fixed" by browsers like firefox but because of the loss of precision they do the wrong thing.
Turning off this clean up helps in this case but for this issue alone is not really the right answer because we it takes away a security feature and a well-formed markup feature... so there may need to be some adjustment to the handling of at least certain empty tags (other than turning them in to invalid singleton tags.)
All this brings us to the second concern which is do we always want those features in play? Our use-case says no. We want the user to be able to spit out whatever markup they want, invalid or not. We're not putting the form in an app that needs to protect the user from cross script coding, we're building a tool that lets users edit web pages -- hence we have turned off the clean-up.
But turning off cleanup wholesale? Well it's important that we can do it if that's what our usecase calls for but the implementation we have is all or nothing. It would be nice to be able to define strategies for cleanup. Make that function plug-able. For example:
* In the XML Config of the system define a "map" of config names to class names which implement the a given strategy. In the XForm Def the author would specify the name from the map.
If TagSoup transforms:
Text outside anchor
Into:
Text outside anchor
Wouldn't that be bug in TagSoup? If that was the case, then I'd say that it is better to fix this issue rather than disable TagSoup. But, it isn't a bug in TagSoup; here is what seems to be happening. Say the browsers sends the following to the client:
<a shape="rect"></a>After<br clear="none">
This goes through TagSoup, the result goes through the XSLT clean-up code, and the following is sent to the browser:
<a shape="rect"/>After<br clear="none"/>
The issue is on the browser, which transforms this into:
<a shape="rect">After</a><br clear="none"/>
The problem is that we serialize this as XML with Dom4jUtils.domToString(cleanedDocument), while it would be more prudent to serialize it as HTML. Here we could use the Saxon serializer. It is also used from HTMLSerializer. Maybe you can try changing this code to use it instead of using Dom4jUtils.domToString(). You'll let us know what you find when a get a chance to do that.
Binesh and I agree, if there is a bug it would be a good idea to address the issue closer to the root. But I think the specific issue he is only part of the matter.
We're thinking it would be best to have some kind of name-to-strategy mapping so that RTEs can call in the server-side processing that is right for them or the default if it's not specified.
Is there a way to remove blank pages appearing between two chapters, in Appendix?
Your problem is that all chapters, whether they're in the appendix or not, default to starting on an odd-numbered page when you're in two-sided layout mode. A few possible solutions:
The simplest solution is to use the openany option to your document class, which makes chapters start on the next page, irrespective of whether it's an odd or even numbered page. This is supported in the standard book documentclass, eg \documentclass[openany]{book}. (memoir also supports using this as a declaration \openany which can be used in the middle of a document to change the behavior for subsequent pages.)
Another option is to try the \let\cleardoublepage\clearpage command before your appendices to avoid the behavior.
Or, if you don't care using a two-sided layout, using the option oneside to your documentclass (eg \documentclass[oneside]{book}) will switch to using a one-sided layout.
it is very easy:
add \documentclass[oneside]{book}
and youre fine ;)
I tried Noah's suggestion which leads to the best solution up to now.
Just insert \let\cleardoublepage\clearpage before all the parts with the blank pages
Especially when you use \documentclass[12pt,a4paper]{book}
frederic snyers's advice \documentclass[oneside]{book} is also very good and solves the problem, but if we just want to use the book.cls or article.cls, the one would make a big difference presenting your particles.
Hence, Big support to \let\cleardoublepage\clearpage for the people who will ask the same question in the future.
If you specify the option 'openany' in the \documentclass declaration each chapter in the book (I'm guessing you're using the book class as chapters open on the next page in reports and articles don't have chapters) will open on a new page, not necessarily the next odd-numbered page.
Of course, that's not quite what you want. I think you want to set openany for chapters in the appendix. 'fraid I don't know how to do that, I suspect that you need to roll up your sleeves and wrestle with TeX itself
In my case, I still wanted the open on odd pages option but this would produce a blank page with the chapter name in the header. I didn't want the header. And so to avoid this I used this at the end of the chapter:
\clearpage
\thispagestyle{plain}
This let's you keep the blank page on the last even page of the chapter but without the header.
I put the \let\cleardoublepage\clearpage before \makeindex. Else, your content page will display page number based on the page number before you clear the blank page.
One thing I discovered is that using the \include command will often insert and extra blank page. Riffing on the previous trick with the \let command, I inserted \let\include\input near the beginning of the document, and that got rid of most of the excessive blank pages.
You can also use \openany, \openright and \openleft commands:
\documentclass{memoir}
\begin{document}
\openany
\appendix
\openright
\appendixpage
This is the appendix.
\end{document}