Numerous mp3s. All have id3 tags. I want to know what the tag version is on a specific mp3. I do not see this information in iTunes. So, I do not know if it is 1,2,2.x, etc. I also have MusicBrainz as an option, but still do not see id3 version displayed anywhere.
Q) Do either of these applications display id3 tag version information? Are there simple command line programs which will display tag version on all the different versions? 2.x, 2.x+1, 2.x+2 etc...
Thx
Related
We recently upgraded to pylint-1.1 from pylint-0.28, and I can no longer get the message ids written to the html files generated when using --output-format=html.
Changes in pylint 1.X took away the --include-ids option, and these questions:
How do I get Pylint message IDs to show up after pylint-1.0.0?
PyLint 1.0.0 with PyDev + Eclipse: "include-ids" option no longer allowed, breaks Eclipse integration
suggest using the --message-template option to restore it, but that only seems to work with screen output. So, currently the 'type' column in the html file only contains one of the five message types. How can I get the message name or message id into the html files instead?
Also, FWIW the pylint documentation here
https://pypi.python.org/pypi/pylint
http://docs.pylint.org/features.html#options
still mentions the --include-ids option, and doesn't mention --message-template.
Mark E. Hamilton
That's right that this option disappears in pylint 1.1.
Text reporters advantagously get the message-template instead, but HTML loose a bit of configurability on the way. Anyway IMO, the html reports should be fixed to systematically include the symbolic name and that's it.
Please submit an issue on https://bitbucket.org/logilab/pylint/issues about that.
Some questions for this very nifty tool, unfortunately lacking many usage examples.
Manual speaks of a possible “Reduced Functionality” for wkhtmltopdf. I have version wkhtmltox-0.11.0_rc1-installer.exe, by running wkhtmltopdf --version what should I read to understand whether my version is the reduced one or not?
Currently I like wkhtmltopdf for webpages I want to read later and/or store. To mirror webpages I use httrack, then I generate the PDF with wkhtmltopdf *.html offline.pdf. How can I set/specify the first PDF page from the *.html list? Currently they seem to be converted in alphabetical order.
If I run wkhtmltopdf toc http://qt-project.org/doc/qt-4.8/qstring.html qstring.pdf I simply get a leading blank page, no TOC. What’s wrong?
Thanks for helping
EDIT:
#Nenotlep:
Your TOC trick works perfectly.
As for the first page, I don’t need an actual cover.
What I need is a way to download/convert a given page www.site.com/foo.html and all the linked pages (A.html, B.html ...) up to a certain depth level. Then I want a single PDF starting with foo.html and containing also the pages A.html, B.html ... (with relative links).
I don’t think there is an option to download and insert the linked pages in the final PDF (please, correct me if I am wrong). So I use httrack.com to download and wkhtmltopdf to convert. Given the alphabetical behaviour of wkhtmltopdf, the best now seems to rename the target page, downloaded with httrack, something like !foo.html.
Please, let me know of possible alternatives.
For part 3 of the question which is blank TOC, the latest stable version 0.12.5 also does not generate it. The pre-release version 0.12.6-dev has fixed this problem in Mac.
I think all available precompiled wkhtmltopdf's are compiled with the patched QT, they are not reduced. The reduced functionality means that it was compiled without a special patched version of QT. I use the windows version and it isn't reduced.
I think the cover command line argument would work for you. I can't test at the moment, but try a command like wkhtmltopdf cover derpy.html toc --xsl-style-sheet default.xsl rarity.html twilight.html spike.html equestriadaily.pdf
At least in Linux, I think the asterix *.html simply explodes into all the html files before the command is performed, so if you select one html file for the cover and then do *.html in the same folder you will get the file twice. Getting around this issue might need some command line sorcery or a batch file or some other trickery.
This is a bug in wkhtmltopdf. The workaround is to manually set a tocfile. You can get the default tocfile with wkhtmltopdf.exe --dump-default-toc-xsl. Then you can save the output as a file and use it like wkhtmltopdf.exe toc --xsl-style-sheet default.xsl www.stackoverflow.com so.pdf.
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.
I've installed wkhtmltopdf on Mac OS X via homebrew and I've also tried compiling it (along with the patched version of Qt) by hand. In both cases, the PDFs it generates do not contain any selectable, copyable, or searchable text. Instead each page seems to be its own monolithic image.
However, the binary version for Mac OS that's provided on the website does produce selectable text. But it's an older version (0.9.9) and does not support some of the newer features in 0.11 rc1 that I need.
How do I get newer versions to produce PDFs with selectable and searchable text?
Currently there is a bug in the queue of that project for just this case.
Unfortunatly, the recent binary for Mac OSX (0.11-rc1) still has this problem
You can get a older (but newner than the original poster's version) version (0.10) that does work here.
Ensure the body element has a defined, non-zero height.
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.