I am using the program groff to format text. groff is hyphenating words and breaking them onto multiple lines. I would not like it to do that.
The manual outlines methods for disabling hyphenation. However, I can't figure out how to invoke .hn at the command line. Is there a way to pass command line flags to groff to disable hyphenation?
Thanks,
Kevin
Taken from the awesome Run aspell on manpage.
You should pass the HY register with the value 0 with the -rHY=0 command line flag.
Command line flags to groff are documented via man groff_man. This manual page is available in Ubuntu/Debian through the groff package (not included with the groff-base package, which does include the groff binary).
The value 0 of HY is actually not explicitly documented as a way to disable indentation, but it seems to work!
For what it's worth, the hyphenation difference was appearing because my colleague was using groff version 1.22.3 and I was using groff 1.22.4. 1.22.3 does not use as aggressive hyphenation.
I suspect that there is no way to control hyphenation at the command line.
Related
I'm using Julia in a jupyter notebook.
I want to generate a pdf for the results of my work. However, when generating the pdf, the λ of the mathematical expression λ=3 is lost so that the output in the pdf is =3.
Here is the jupyter notebook code
In[1]: λ=3
Out[1]: 3
Here is the pdf generated with the jupyter notebook
In[1]: =3
Out[1]: 3
This is not the case in with the pdf generated with nteract where the expression λ=3 is fully printed out. However the overall appearance of the pdf generated with nteract is not as nice as the pdf generated with jupyter notebook.
Here is printed pdf generated with nteract (looks exactly the same as the code itself):
In[1]: λ=3
Out[1]: 3
Can somebody know how to print such character with jupyter notebook?
Many thanks in advance
The issue is related to how Jupyter itself generates and compiles the latex file. Jupyter, by default, compiles the file with xelatex to support Unicode. My guess is, however, xelatex requires some configurations in the files and Jupyter does not generate the file that works out of the box with plain xelatex command.
You can change the configuration of Jupyter to compile latex file generated with pdflatex or latex command.
Solution:
Find your Jupyter configuration directory(i.e. output of jupyter --config-dir, on Linux usually ~/.jupyter. To find out which jupyter IJulia uses run using IJulia; IJulia.jupyter then find out the config directory of that jupyter)
Create the file jupyter_notebook_config.py in this directory if there is not one, already.
Put the following line of code at the end of this file and save it:
c.PDFExporter.latex_command = ['pdflatex', '{filename}']
Then you can export the PDF file using the notebook, as usual. The characters should appear, just right. This should work provided that pdflatex command is found in your shell.
If you do not have pdflatex but have latex you can also use the following line instead of the code above:
c.PDFExporter.latex_command = ['latex', '--output-format=pdf', '{filename}']
If you are not able to change the configuration of Jupyter, download the latex file and compile it with the command latex --output-format=pdf filename.tex.
Hope it works!
My solution to this is ugly, and I will get to it below, but first it is important to understand why this is happening.
Why is this happening
The intermediate .tex file that is generated indirectly calls for the Latin Modern fonts. Latin Modern is a fine choice for math fonts, but it is sucky for monospaced. The Latin Modern mono font does not include Greek.
Latin Modern is set by the unicode-math LaTeX package, which is loaded in the generated LaTeX around line 43.
\ifPDFTeX
\usepackage[T1]{fontenc}
\IfFileExists{alphabeta.sty}{
\usepackage{alphabeta}
}{
\usepackage[mathletters]{ucs}
\usepackage[utf8x]{inputenc}
}
\else
\usepackage{fontspec}
\usepackage{unicode-math}
\fi
So the unicode-math package will be loaded if you are using XeLaTeX (which is a good default) or LuaTeX or any other LaTeX engine for which fontspec is available.
The unicode-math package very reasonably uses Latin Modern for math, but if nothing is set otherwise, it will also use Latin Modern for monospaced fonts. From the documentation
Once the package is loaded, traditional TFM-based maths fonts are no longer supported; you can only switch to a different OpenType maths font using the \setmathfont command. If you do not load an OpenType maths font before \begin{document}, Latin Modern Math will be loaded automatically.
The creators of unicode-math assume that you will set your non-math fonts up after you have loaded the unicode-math, but that isn't done with the .tex generated by jupyter nbconvert. (I don't know if this is a jupyter thing or a Pandoc thing, but either way we end up with a document that is used Latin Modern for more than just math.)
So one solution is to set some other mono font after unicode-math is loaded and before \begin{Document}.
My solution
My solution is tuned for what I already had set up. It may not be the right approach for you, and it certainly will need some adjusting.
My Makefile used to have a simple juypter nbconvert --to=pdf in it. But now I need to edit the intermediate .tex file. So I have this for a notebook named computation-examples. You will need to use your own file name or do some Make rule magic.
# sed on macOS is just weird. Resorting to perl
computation-examples.tex: computation-examples.ipynb
jupyter nbconvert --to=latex $<
perl -pi -e '/^([ \t]*)\\usepackage{unicode-math}/ and $$_.="$$1\\usepackage[default]{fontsetup}\n"' $#
The perl adds the line \usepackage[default]{fontsetup} immediately after the line with\usepackage{unicode-math}. There are probably nicer ways to do that. I started with sed, but gave up. So the .tex file that is then processed to PDF by XeLaTeX has this.
\else
\usepackage{fontspec}
\usepackage{unicode-math}
\usepackage[default]{fontsetup}
\fi
The fontsetup package preserves all of the goodness of unicode-math while setting up the non-math founts. The default is to use the OpenType (.otf) Computer Modern Unicode fonts that will be a part of any TeX distribution that has xelatex on it.
Another approach
Probably a cleaner approach, but one I haven't experimented with, would be to create a fontspec.cfg file which lies about (overrides) what font files to load for what we are calling Latin Modern Mono. I would need to reread the fontspec documentation for the hundredths time to do that.
Make magic
Since writing the above, I have set up a more general Makefile rule,
%.tex: %.ipynb
jupyter nbconvert --to=latex $<
perl -pi -e '/^([ \t]*)\\usepackage{unicode-math}/ and $$_.="$$1\\usepackage[default]{fontsetup}\n"' $#
which sits along rules to make a PDF from a .tex file.
But if you aren't using make and Makefiles, then you can wrap up that perl monstrosity into a script of your choosing.
Shown in the image below, the git prompt has overlapping glyphs.
I installed this theme by following the instructions listed Here. What doesn't make sense is that all prompts other than the git prompt look completely fine. So I guess the question is why would the git extension only be affected by this glyph misalignment?
I've been trying to do my best to research into any similar issues but could not find any thing outside of questions such as this.
The environment that I am using consists of the following
Kubuntu 15.04
Konsole
Tmux
zsh
xterm-256color
oh-my-zsh
powerline status bar
powerlevel9k theme
Font : ubuntu mono derivative powerline
My .zshrc contains these two lines to engage the powerlevel9k theme
ZSH_THEME="powerlevel9k/powerlevel9k"
POWERLEVEL9K_MODE="awesome-fontconfig"
Any insights on tweaking these glyphs will be incredibly helpful. So thanks in advance!
powerlevel9k uses in "awesome-*" mode the awesome-terminal-fonts. Some of the glyphs in there are double-width, which is why we added some extra whitespace to these icons (see here). Most of us use the "awesome-patched" mode, which requires pre-patched fonts, but is easier to install.
A quick shot would be to add some more whitespace. Could you try that, and if that works add a pull request? That would be nice.
Another guess in the wild is: what locale do you use? We had some strange issues with LANG=C. If that is the case on your machine, try setting it to a proper UTF8 one.
My documentation management app involves converting a .docx file containing non-ASCII Unicode characters (Japanese) to PDF with docsplit (via the Ruby gem, if it matters). It works fine on my Mac. On my Ubuntu machine, the resulting PDF has square boxes where the characters should be, whether invoked through Ruby or directly on the command line. The odd thing is, when I open up the .docx file directly in LibreOffice and do a PDF export, it works fine. So it would seem there is some aspect to how docsplit invokes LO that causes the Unicode characters to be handled improperly. I have scoured various parts of the documentation and code for options that I might need to specify, with no luck. Any ideas of why this could be happening?
FWIW, docsplit invokes LO with the following options line in pdf_extractor.rb:
options = "--headless --invisible --norestore --nolockcheck --convert-to pdf --outdir #{escaped_out} #{escaped_doc}"
I notice that the output format can optionally be followed by an output filter a in pdf:output_filter_name--is this something I need to think about using?
I have tracked this down to the --headless option which docsplit passes to LibreOffice. That invokes a non-X version of LO, which apparently does not have the necessary Japanese fonts. Unfortunately, there appears to be no way to pass options to docsplit to tell it to omit the --headless option to LO, so I will end up patching or forking the code somehow.
Ever since OS X 10.7.3, my text editor is setting the "quarantine" bit on any file it touches.
My text editor is designed for working with shell scripts, and if the quarantine bit is set then a shell script cannot be executed from the command line, until you double click it in Finder and go through a "This application was downloaded from the internet" alert (or remove the quarantine bit with xattr).
For example, I just created a "hello world" script in my app, it has been quarantined, and cannot be executed:
$ xattr -l foo
com.apple.quarantine: 0006;4f51dd2f;Dux;
$ chmod +x foo
$ ./foo
-bash: ./foo: Operation not permitted
If I remove the quarantine bit, the script works:
$ xattr -d com.apple.quarantine foo
$ ./foo
hello world
According to some forum posts, TextEdit also sets the quarantine bit on any shell script it creates.
I'm using a simple NSDocument subclass to create the file:
- (NSData *)dataOfType:(NSString *)typeName error:(NSError **)outError
{
return [self.textStorage.string dataUsingEncoding:self.stringEncoding];
}
How can I remove the quarantine bit from files created in my app? Other text editors, such a TextWrangler, do not set the quarantine bit.
UPDATE
A little more info, this only occurs when creating a "script application" file, which is anything from perl scripts to html.
And it only occurs when my app is sandboxed. Disabling sandboxing fixes the problem, but that's not a long term solution.
I've filed a bug with Radar, it looks like there might be nothing to do but wait/hope that avenue gets it fixed.
Try ensuring that the LSFileQuarantineEnabled in your Info.plist is set to false (which should be the default). If the attribute is still being set, then I'd suggest filing a bug report and removing it programmatically with removexattr(2)/fremovexattr(2)
Nice to know that I'm not the only one with this problem - which has been difficult to track-down information on. I've found this problem occurs with data files saved by my program (these are not scripts, they are just XML data...).
I confirm that LSFileQuarantineEnabled made no difference.
I also tried to remove the attribute after the file was written, using removexattr http://hints.macworld.com/article.php?story=20071029151619619, but this didn't work either - the sandbox prevented the call from working.
By way of background, I also found this discussion of the problem:
http://reviews.cnet.com/8301-13727_7-57374676-263/workarounds-for-quarantine-bug-in-os-x-lion/
For the record, I've separately raised a bug with Apple.
EDIT: I have found the source of the problem, and figured-out the work-around.
The problem was that if the file data is plain XML format data, MacOS mistakenly displays the reported message (I think this is because it wrongly assumes that the file is a script). If I change the file format to be an alternative that clearly isn't XML, the warning disappears. The file is still saved with the quarantine bit set, however!
So this is definitely due to an issue in MacOS, but there is a relatively easy work-around - just change your file format!
As far as I can tell, this bug has been fixed in OS X 10.8 (Mountain Lion).
Seems like I will have to make 10.8 the minimum OS version for my app. Not really a big deal for me... but hopefully Apple fixes it in a bugfix to 10.7 (the system requirements for 10.8 are quite a bit higher than 10.7, I know people who can't upgrade).
Is it possible to remove a specific layer in a pdf file with ghostscript ? (with linux command line)
You can use the gs command here to figure out where the OCRed text is and, as #LarsKotthof suggested here, use PDFCrop to remove the margins that contain text.
No. As far as I know, none of the Linux commandline tools to handle PDF files can do that.