I just found out that I can change window size and position via ~/.gazebo/gui.ini file fields. Now I wonder what else fields it can have? Is there specification/docs/tutorial for this file? I couldn't find any of that.
Related
Well, to start with, I don't know much about Latex. I am failing to include a picture in to the document using "Moderncv Casual". A lot of the CV's and cover letter's template using:
\photo[64pt][0.4pt]{filename}
What's the deal with this? Is it not just to type the pictures's filename, compile, and the picture should be added to the document?
That's exactly it. The \photo macro is set up in such a way that it stores your input and makes it part of the CV title (set with \makecvtitle).
The reasoning behind this is to provide the end-user with a generic command to would capture a picture. However, depending on the template used, this picture may appear on the left/right/middle (or wherever). The generic input abstracts this placement from the rest of the code.
Specific to the command \photo; it is defined inside the class moderncv.cls file as:
\NewDocumentCommand{\photo}{O{64pt}O{0.4pt}m}
{\def\#photowidth{#1}\def\#photoframewidth{#2}\def\#photo{#3}}
An input like
\photo[64pt][0.4pt]{filename}
defines the photo to be kept in \#photo - it references the image file filename (with an image extension) - to have a width of 64pt (stored in \#photowidth) and frame width 0.4pt (stored in \#photoframewidth).
XRef table at offset 666027 has /Prev entry as 0, which seems to be wrong, how to handle such pdfs, how to get the actual /Prev in such cases?
Please look into attached pdf http://www.filedropper.com/hackermonthly-issue-11
Acrobat opens it 'as usual' but then wants to save it on closing. This is an indication it "repaired" the file; probably by enumerating the objects in the file and ignoring the xref tables.
Technically speaking, the file is damaged and there is no right way to "handle" it. Opening then saving it with Acrobat may work for some files, but is it not totally fail-safe; Acrobat still has to guess which objects are still valid and which are not.
The PDF was originally created with Adobe InDesign CS5, which is not known to generate faulty PDFs, and one can assume the tool that was used to add the annotations damaged the file. A cursory glance at the end of the file confirms this: the startxref offset is off by a couple of bytes, and when fixing this with a hex editor, you will only find the previous startxref (for another annotation) is also off by a couple of bytes – at which point I gave up and did not check further. So whatever tool you used to annotate the PDF, don't use it anymore.
I have created a global data type, and use form renderer in a page to let user fill in the data and submit to website.
The default English is working fine.
now when I try to support the second language I run into issues. According to the composite documentation:
1.Add your empty localization file at ~/Frontend/CompositeForms/Renderer/Localization/, for example: Composite.FormsRenderer.de-de.xml
2.Copy the contents of the default Composite.FormsRenderer.en-us.xml to your localization file.
3.Translate the strings.
4.In ~/App_Data/Composite/Composite.config, under the section locate Composite.Plugins.FormsRenderer's add section and register your localization file
but ~/Frontend/CompositeForms/Renderer/Localization does not exist, and neither does Composite.FormsRendereren-us.xml exists.
is the documentation outdated? does anyone had experience with localizing form renderer on user defined data type?
thanks
The documentation IS outdated at the moment (and will be updated soon - thanks for pointing it out).
Do it in the following way on 4.0 or later:
Make a copy of ~/Composite/InstalledPackages/localization/Composite.Forms.Renderer.en-us.xml, changing the language/culture code from 'en-us' to your language's (e.g. Composite.Forms.Renderer.de-de.xml).
Translate the strings.
No need to change anything in ~/App_Data/Composite/Composite.config any more.
I have a database which I want to export as an iOS compatible PLIST.
The work around I have come up with is to create a calculated field which adds the tagged padding and header and creates a report using these fields. I then export the preview of the report as a PDF, open the PDF in Acrobat Reader, select all text, copy and paste into XCode which recognises the PLIST format and all works as expected.
Is there a better way of doing this? (This seems a really convoluted way of doing things, high chance of error, etc.) The Export as XML option looks promising but I can't seem to join the dots.
Two ways that I can think of to do what you're trying to do. The most elegant way is probably the XML with XSLT export which you suggest. If you don't already know XSLT, though, you might try the following -- it sounds like with the calculated XML line you've already created, like this would be a simple change to your database:
Create a single new global field, say outputXML
Create a script, say plistCreator
In the plistCreator script:
Set outputXML to ""
Go to the first record you want to export
Loop through every record putting your calculated XML line into outputXML (set field outputXML to outputXML & ¶ & calculatedXMLLine)
Go to next record, exit after last
Export Field Contents (note that this is a different command than Export) for outputXML
The cleanest solution is to use the export XML with an XSLT for transforming the output. You'll need to know a little XSLT to do this, or at least be able to customize the examples from FileMaker.
Is it possible to use a .bb file (generated with, for instance, the "ebb" program included in MiKTeX) to define the bounding box of .png files when using \includegraphics?
I can define the bounding box in the optional argument to \includegraphics directly, like \includegraphics[bb=0 0 100 100]{file.png}, but I'd like to be able to define this outside of the code, using the generated .bb file. Is this possible?
I figured it out. Applying
\DeclareGraphicsExtensions{.png, .bb}
\DeclareGraphicsRule{.png}{eps}{.bb}{}
before including graphics using \includegraphics{file} (without the extension) solved it. :)
Just in case someone have the same problem.