Using FPDI, I first use a template to create a table of contents. I then import additional pages, which are linked to by the table of contents. What I'm experiencing is that FPDI is shrinking the templates and possible adding white space. I believe I have eliminated any browser added whitespace/shrinkage by merging the same documents into one via the passthru() command.
I have pasted code here: http://pastebin.com/VeLEN8nz. Line 45 - 57 is where the Table of Contents gets included as a template file.
The original file is here: http://truckingshow.com/TOC.pdf
The post-FPDI file is here: http://truckingshow.com/TOC-afterFPDI.pdf
The most noticeable difference is in the right and bottom margins.
Thank you for taking a look, please let me know if I can provide more info.
The document that was given to me was "Letter", not "A4" (the default for FPDF())
Instead of $pdf = new FPDI('P', 'pt') Simply using $pdf = new FPDI('P', 'pt', 'Letter') solved the problem.
Thanks!
Related
I am creating a thesis paper with a class file created by my institution, however, the code for the class file is outdated and doesn't fit the exact requirements necessary for the format submission.
The font is size 12 and the margin specifications are as follows (These values give us 1.6in on the left margin,and 1.1in on the other margins, as well as placing the page numbers):
\newlength{\#realheadsep}
\newlength{\#realtextheight}
\makeatletter
\setlength{\oddsidemargin}{.6in}
\setlength{\textwidth}{5.8in}
\setlength{\marginparsep}{.2in}
\setlength{\marginparwidth}{1in}
\setlength{\topmargin}{-0.5in}
\setlength{\headheight}{0.25in}
\setlength{\#realheadsep}{0.35in}
\setlength{\#realtextheight}{8.8in}
\setlength{\footskip}{.5in}
\setlength{\paperheight}{11.0in}
\setlength{\paperwidth}{8.5in}
\setlength{\headsep}{\#realheadsep}
\setlength{\textheight}{\#realtextheight}
\setlength{\headsep}{\#realheadsep}
\setlength{\textheight}{\#realtextheight}
% set paragraph indentation to 2em
\parindent 2em
% Lengths used by capheadings where we expand the header and shrink
% the text body to allow the heading on each page within original margins.
\newlength{\#headerextra}
\setlength{\#headerextra}{0.35in}
\newlength{\#altheadsep}
\setlength{\#altheadsep}{\#realheadsep}
\addtolength{\#altheadsep}{\#headerextra}
\newlength{\#alttextheight}
\setlength{\#alttextheight}{\#realtextheight}
\addtolength{\#alttextheight}{-\#headerextra}
\newlength{\#fullheadheight}
\setlength{\#fullheadheight}{\headheight}
\addtolength{\#fullheadheight}{\#realheadsep}
\newlength{\#headtofootheight}
\setlength{\#headtofootheight}{\#alttextheight}
\addtolength{\#headtofootheight}{\#realheadsep}
\addtolength{\#headtofootheight}{\#headerextra}
The automatic table of contents is missing a few attributes and I am unable to edit the class file to fix it/ add in chapters and such manually.
My current automatic table of contents looks like this (but it is missing a few things that I need to add manually):
Does anyone know how to either manually code this in another latex file so I can change my table of contents? It needs to match this format.
Thank you in advance! If there is any information that you might need from the class file, please let me know and I can try to find it.
I'm working on a theme for Wyam and I'm wondering if there's a way to set the layout that should be used in the markdown file for a particular page. As far as I have seen so far, it seems that each page created with markdown uses _Layout.cshtml
To be more specific. I'm creating an "about.md" page, which has a different layout then then other (default) pages.
So what I would like to do is use metadata to select the layout. For example
Layout: _About.cshtml
or
Layout: _About
Is this possible with Wyam?
In A Razor File
Pages in the Wyam recipes (I'm assuming you're using either the blog or docs recipe) are processed by Razor. The use of a _Layout.cshtml is by convention in the recipe, but alternate layouts can be specified using standard Razor syntax. You can do so by placing the following at the top of the about page .cshtml file (under your front matter):
#{
Layout = "_About.cshtml";
}
In A Markdown File
Markdown files are also processed by the Razor engine, so the technique above would work if it weren't for the Markdown processor escaping the # symbol. There's really no good way around that, and the simple answer to your question is you can't specify an alternate layout for a Markdown file.
However, one of the advantages of using a code-driven generator like Wyam is that you have a lot of control. In this case, you can replace the RenderPages pipeline with one that will do exactly what you want. Add the following to your wyam.config file:
int index = Pipelines.IndexOf(Blog.RenderPages);
Pipelines.Remove(Blog.RenderPages);
Pipelines.Insert(index, Blog.RenderPages,
(IPipeline)new Wyam.Web.Pipelines.RenderPages(
Blog.RenderPages,
new Wyam.Web.Pipelines.RenderPagesSettings
{
Pipelines = new string[] { "Pages" },
Layout = (doc, ctx) => doc.String("Layout", "/_Layout.cshtml")
}));
Then you'll be able to add a "Layout" value as front matter exactly like you wrote in your question.
This was a good idea in general, so I've also opened an issue to add this behavior to the recipe by default.
I'm kinda new to typo, so maybe I am just missing something.
I'm trying to add a third content field to Typo3 4.5.
What I've done so far.
Edit my template and added a new block
Added the block via TemplatVoila > Update Mapping > Modify DS / TO with Element Preset "Page-Content Elements [Pos.: 0]
Mapped it to the new block in the template
But I am missing something as the new field isn't showing up in the Page edit screen.
EDIT: I've found the Block in the "Edit page properties" but how to show it on standard edit screen?
Any added content area will appear automatically in your TV-View-module. So if you dont see it in there, then
you may have duplicate fields names
wrong column positions
or the existing template is using a »beLayout«-section, which shows only the first two content areas (see example in reference http://docs.typo3.org/typo3cms/extensions/templavoila/ExtTemplavoila/StaticDataStructures/ExampleForBelayout/Index.html)
The TemplaVoila template is split into TS (TemplaVoilà Template Object) and DS (TemplaVoilà Data Structure) records, may you paste the content of the field „Data Structure XML“ of the DS record here? In there are all necessary information.
The two template files should be located in your general storage folder, your TypoScript root file should be there as well.
I am stitching a couple of documents together with a requirement that each document should retain its header and footer information in the final document. Using AltChunk instead of raw OpenXml or DocumentBuilder saves a lot of effort with regards to styles, formatting, references, parts, etc.
Unfortunately, after a couple of days I can't seem to get a 100% working version due to a small and frustrating issue and I need some insight.
My code is loosly based on this article
I modify each sub document, prior to appending it (as an AltChunk) to a working document, by moving the last section properties into the last paragraph (in order to retain header and footer references), but Word seems to be adding a blank paragraph to each of these documents as it renders them in the final document. I end up with:
document 1 with correct header and footer
section properties/break
blank paragraph
document 2 with correct header and footer
section properties/break
blank paragraph
etc.
I cant remove the blank paragraphs afterwards, as I ideally don't want to use WAS to render the document first.
It seems as if you cannot have a next-page section break without a following paragraph?
After further investigation, it seems that will not be away around my usage scenario. I would need to place the last section properties in the body element, but due to my way of processing with nested AltChunk, it would not work.
I have changed my approach completely and went back to a more detailed append procedure using OpenXml Power Tools and some LINQ to Xml.
I'm using Document Builder and works perfectly for me!
var sources = new List<OpenXmlPowerTools.Source>();
sources.Add(new OpenXmlPowerTools.Source(new WmlDocument(#tempReportPart1)));
sources.Add(new OpenXmlPowerTools.Source(new WmlDocument(#tempReportPart2)));
var outputPath = #"C:\Users\xpto\Documents\TestFolder\myNewDocument.docx";
DocumentBuilder.BuildDocument(sources, outputPath);
I have the similar empty paragraph issue while importing HTML files.
My solution is,
After inserting HTML AltChunk, I add a GUID place holder. After processing the file, I will open the file again, locate the GUID and check if there is a empty paragraph before it, if so remove the empty paragraph and GUID. it seems work perfectly in my solution.
Hope it helps.
My news should not contain any text, except for the title. Instead, in the list view the title should directly point to the first attached file (a PDF).
Now I thought the simplest solution for that would be to hide the title, show only the attached files and give them the title of the related news entry via TypoScript.
For the detail view this code works fine:
plugin.tt_news.newsFiles {
labelStdWrap.cObject = TEXT
labelStdWrap.cObject.dataWrap = DB:tt_news:{GPvar:tx_ttnews|tt_news}:title
labelStdWrap.cObject.wrap3 = {|}
labelStdWrap.cObject.insertData = 1
}
...but it uses the GPvar for the currently displayed news, which of course is not present in list view.
So my question is: how do I get the ID of the currently iterated news entry, if possible at all?
I am open to other solutions as well.
You will need to use custom itemMarkerArrayFunc - fastest by copying the sample into your own extension: typo3conf/ext/tt_news/res/example_itemMarkerArrayFunc.php and adding custom marker to $markerArray.
The mentioned sample even demonstrates access to files so I assume that should not be a problem to modify it for your needs.
Note: if you haven't any own ext to copy the func into it, and you don't want to create such, try to copy it somewhere under fileadmin folder, modifying files in original destination is wrong idea, cause you'll lost all changes after next tt_news' update.
Easiest solution I found is using the labelStdWrap:
plugin.tt_news.newsFiles {
labelStdWrap = TEXT
labelStdWrap.field= title
}
More options can be found here: http://typo3.org/documentation/document-library/core-documentation/doc_core_tsref/4.0.0/view/5/13/