I have created a PDF from several web pages using wkhtmltopdf.
Is there a way to link across pages, for example from page 10 to 15.
I tried creating an element with an ID and then an anchor to link to it, but this does not work within the same page or across pages. It turns the link into an absolute URL and tries to open it in a web browser.
I solved this issue by updating the binary that I was using.
I was using 0.8 and switched to 0.11.0 rc1.
Ensure that it is built against QT (the latest binary at http://code.google.com/p/wkhtmltopdf/downloads/detail?name=wkhtmltoimage-0.11.0_rc1-static-amd64.tar.bz2 is.
And then just to be sure enable internal links:
--enable-internal-links
when you call the conversion
i had this issue after installing pathced version of QT
i had wkhtmltopdf 0.9.6, than i also switched to 0.11.0 rc1
then worked fine!
and no need to use --enable-internal-links. you can just turn off this option by --disable-internal-links* by default its on.
Internal links appear only to work correctly in certain builds for certain platforms. With the latest WkHTMLtoPDF 0.12.5 releases the unix builds are OK (at least for Centos and Ubuntu) and internal links are generated correctly BUT windows builds DO NOT work and leave broken links. I don't know why this is and have commented on GitHub accordingly.
Also when multiple html input documents are used any 'internal' hyperlinks between these are broken (all platforms). In other words cross input document links are NOT fixed up. This would be a really useful feature addition (particularly when generating massive reports) but sadly does not appear to be supported as yet.
Related
I am trying to get phpDocumentor2 to build API documentation for a PHP project I am working on.
The problem is that the HTML output landing page does not show the packages defined in my project. It only shows "Global ()" package.
I believe I am properly using the #package tag for my classes. phpDocumentor version is 2.0.0b4.
In my efforts to find the bottom of the problem I found a project that is already using phpdoc2. I downloaded that project and tried to build the documentation myself as it has a phpdoc.dist.xml file in its codebase root. I got the same problem: no packages in HTML output landing page, while the vendor's one is showing them (SimplePie, CodeIgniter, Streams etc.).
How can I get my phpdoc output showing packages?
I think you are experiencing a bug in the early betas. Keep watching for new beta releases, as they are coming out quite fast as bugs are reported and fixed.
I'm new to Firefox extension development, friendly speaking it's first day, I had followed the following article in order to start with Firefox extension development: How to develop a Firefox extension.
If I download the example from above given link's tutorial and try to install, it is installed perfectly but, when I update that example (just updating its name to the new extension name, where it is necessary in all files), and then install, I get the following message: "X could not be installed because it is not compatible with Firefox 15.0.1." (where X is the name of my extension).
Strange behavior same code one is installing fine and other one giving error.
Any idea where it is going wrong and what is causing this?
The problem is that you forgot to adjust the compatibility range in install.rdf so em:maxVersion is still saying 3.1b2 (meaning Firefox 3.1b2 - a rather old version). You should change that into 15.* if you want to support the current stable Firefox version or 16.* if you want to support the current beta versions. You can also change em:minVersion into something more meaningful: I doubt that you will verify whether your extension still works with Firefox 2.0.
As to why the extension installs if you don't change the extension ID, this is more complicated. First of all, there is a soft override mechanism for the compatibility ranges which allows extension authors to change the compatible version range without releasing a new version. In this particular case Firefox will check for extension updates by requesting this address or a similar one. The update server tells it that version 1.0 is still current but adjusts maxVersion to Firefox 8.0 - this value will override whatever is specified in install.rdf.
But that's not the end of the story. The compatibility check mechanism was changed significantly in Firefox 10, the default assumption is now that the add-on is compatible with newer versions even if that isn't specified explicitly anywhere. The requirements are that the extension doesn't opt out of lax compatibility checking, doesn't contain binary components and is compatible with at least Firefox 4. The original extension is compatible with Firefox 8 thanks to the soft override, with a different extension ID it is only compatible with Firefox 3.1b2 however (it isn't hosted on addons.mozilla.org so the update server doesn't know about it) which means that the lax compatibility checking doesn't apply to it.
For reference: the behavior described in the previous paragraph is controlled by the extensions.strictCompatibility, extensions.minCompatibleAppVersion and extensions.minCompatiblePlatformVersion preferences.
Asked this on superuser.com, not sure if stackoverflow is a better suitable place for it, but I am not getting any answers yet:
===
I am trying to generate a new blog entry in my octopress setup, but I noticed that some previous posts are being generated as empty files in public, so are the new ones I am trying to generte.
There seems to be no difference at all between the markup files from one entry which is being properly generated to another that isn't
I've got two octopress installations, one's working and this one I am talking about isn't, updates octopress on both, reinstalled bundle but no luck, files as atom.xml are also not being generated correctly.
Also updated from ruby 1.9.2p290 to latest release from 1.9.3 but also did not difference.
Anyone's encountered this before?
===
This is most likely because you started using codeblocks. This was happening to me, and even posts/pages that didn't use codeblocks would fail to generate. My problem (on Windows) was that I didn't even have Python installed (thought I did). Installing it fixed the problem, then gave me another error, which was fixed by updating the pygments.rb (note .rb) gem. Doing these two things fixed all my problems.
There's a similar issue if you're on arch linux which defaults python to version 3 which isn't supported by pygments.rb yet. You'll have to look around to figure out how to fix that to use 2.7 instead, but it should be pretty straightforward.
Can you provide an example of: a) a post that doesn't generate correctly, and b) a post that does generate correctly?
I assume they are just individual posts (and not, for example, pages like /about/). I would also assume that they render as blank both in the blog index on your front page and on the individual post page.
Also - what does render? Is it rendering the rest of the page, but just without the "content" of the post itself? Or does the page not even exist? (404?)
In a previous project I wrote a Firefox extensions - nothing too complex - that used xmpp4moz, an add-on for Firefox that integrates the xmpp/Jabber protocol. At that time Firefox 3.6 most the most recent one and everything worked quite well. Now with Firefox 5 xmpp4moz does produces errors, starting with
Error: Component.classes['#something/something/...'] is undefined
and naturally resulting in further 'undefined' errors. In some sense this is ok, since xmpp4moz is officially not available for Firefox 5. And given that the last update was in 2009 I don't really expect a updated version. Currently I see the following two options:
Looking for alternatives/workarounds/...; so far I haven't found anything. Any ideas?
Trying to update/modify xmpp4moz myself to make it running in Firefox 5
The thing is that at the moment I cannot really assess the required efforts.
Summing up, I'm stuck :)
The sameplace download at http://www.sameplace.cc/ appears to include a slightly newer version of xmpp4moz (I didn't really check whether install.rdf is the only difference from the source code repository however). Still, it is only compatible with Firefox 3.6. From the look of it, there are no big issues, main problem is that the XPCOM components aren't being registered. See https://developer.mozilla.org/en/XPCOM/XPCOM_changes_in_Gecko_2.0 for information on the relevant changes, usually updating the components and chrome.manifest is easy.
I am converting some docs to pdf using wkhtmltopdf (currently using perl and the command line versions). Is it possible to change the "PDF Producer", "PDF Version" and "Fast Web View" fields? The current defaults are "wkhtmltopdf", "1.4 (Acrobat 5.x)", and "No", respectively. I didn't see anything in the wiki page
Pass the following with the command line to see supported features: " --extended-help"
Not sure if those specific params are supported or not.
I patched wkhtmltopdf to support an additional flag recently, and it would be quite easy to add parameters to change those. I don't believe they are supported currently, though.
PDF Producer: Nope. Most apps want folks to know that particular app generated the PDF.
PDF Version: Nope, but trivial. The version number at the beginning of the file is just a courtesy really. What exactly are you after with this? Chances are you don't really need it. The PDF generated isn't going to acquire any features automagically just because the PDF claims to be this version or that. It's only really used so a viewer opening a newer PDF can say something like "I don't support this version, some stuff might not work". Because everything will work regardless (unless someone happens to have a VERY old version of Acrobat/Reader), I don't see the issue.
Fast Web View: Nope, and decidedly non-trivial. "Fast Web View" means everything needed to display the first page of the PDF is sorted to the front of the file, and there are various "hints" on where an app downloading the PDF can find this or that. It's not just a flag, not by a long stretch.
Zero for three. Sorry.