How to force non-breaking space in reStructuredText, in code environment? - python-sphinx

I have this snippet in my reStructuredText document:
1. Find the file at ``~/Google Drive/code/mac/install.sh``.
Notice the code/quote environment. Notice the space between Google and Drive in the path.
When rendered with Sphinx in HTML, there is a line-wrap between Google and Drive, and the space is gone. (Since this is documentation, I need everything in the code environment to appear to the user exactly as it is entered, which includes the space between 'Google' and 'Drive'. Not only should a space be present, but it should be shaded grey just like all the other code in the code environment)
How do I tell reStructuredText to use a non-breaking space in that location?

It works for me if the regular space character is replaced with a non-breaking space (U+00A0) in the reST file. That will produce a single <span> element containing Google Drive in the output:
<span class="pre">~/Google Drive/code/mac/install.sh</span>
Inserting a literal non-breaking space can be done in several ways. See https://en.wikipedia.org/wiki/Non-breaking_space#Keyboard_entry_methods.

Put some css in a file _static/custom.css at top repertory in your project
code.docutils.literal {
white-space : pre;
}
(I don't know how from CSS allow breaks say at slashes but not at spaces).
For the approach you can do this:
1. Find the file in our Google Drive folder It is located at
``~/Google`` |_| ``Drive/Quisquam/code/repo/latest/application-bundles/mac/install.sh``.
.. |_| unicode:: 0x00A0
:trim:
Edit: much better than second approach is as pointed in comment to use a NO-BREAK SPACE in the reST source. Then the HTML will use , and the URL will still wrap at slashes contrarily to first approach above which makes it really unwrapping (in my brief investigation).
I had used second approach in other context (also targeting LaTeX output) to insert Unicode+202F, and it had slipped out my mind that for Unicode+00A0, one only has to use it directly in reST source.

The fix for me was to add the following css to the custom.css and make background-color match the pre background-color
tt,
code {
color: #839496;
background-color: #073642;
}

Related

How to add a blank caption for a figure in AsciiDoc

I have an AsciiDoc page which has a number of images. I am converting this into html via antora.
On my AsciiDoc page, some of the images have a caption and some do not.
For the images with a caption, the first one is named "Figure 1. Some interesting caption", then the second one is named "Figure 2. Some fascinating caption" and so on. In fact, the "Figure 1", "Figure 2" text is added automatically by Antora. In AsciiDoc itself, the markup is as follows:
.Some interesting caption;
image::images/image1.png
.Some fascinating caption;
image::images/image2.png
However, now I have a third image which has no caption to display. I would like this image to simply read "Figure 3". However, I do not know how to do this. The only thing I could come up with is to put some character after the "." symbol just above it (I chose a semi-colon), as follows:
.;
image::images/image3.png
This produces "Figure 3;" once converted into html.
It's better than nothing, but I would like to be able to use, for example, a whitespace character, instead of the semi-colon, so that I could simply produce text that reads "Figure 3 " (with an invisible whitespace character that nobody can see). Unfortunately, if I try to do that, the whitespace is ignored and I just see the '.' character in the generated html.
You can use an attribute for the non-breaking space: {nbsp}
For example:
.Some interesting caption;
image::images/image1.png[]
.Some fascinating caption;
image::images/image2.png[]
.{nbsp}
image::images/image3.png[]
Note that I added square brackets to each image macro invocation, because those lines are just text with them. And, there doesn't need to be a blank line between the caption and its associated image.

Ruby PDF::Reader matching bullet point with Regex

I have parsed a pdf document in Ruby with PDF::Reader. The bullet point of the pdf file appears in my parsed text as a strange cube with F0B7 inside like this (I also attached a print screen):
__
|F0|
|B7|
I would like to know if I can match this "bullet point" with regex and if so, what would be the appropriate way to do it? I have absolutely no idea to tackle this issue as I am not even sure that this is part of the string in the first place. Thanks.
This is a unicode symbol with codepoint F0B7.
Unfortunately your Ubuntu installation has a default font that misses that glyph, and when glyph is missing in the font definition, the common approach is to draw it’s codepoint in a square.
The regexp to match it would be:
/\uF0B7/

Visual Studio, cshtml file, understanding how arabic characters are treated

Take the character "ب". It shows in stack overflow. I can see this in a cshtml file and in a js file
The character "ُ" on the other hand shows here correctly. However it shows as a question mark in the cshtml file and js file. If I copy it to notepad it shows as a Ḍammah (a loop normally above a letter which indicates a 'u' sound)
Why is it a question mark in the cshtml file if notepad understands it? ALso Visual Studio understands other arabic characters so why not this one
All I can think of is that a Dammah (as far as I know) always sits above another letter so can't be used in isolation?
What I'm trying to do is detect words that have a Dammah in them via Javascript
I'm completely new to unicode and non acii characters so this may be a stupid question, apologies if so
It often happens that an application uses a default font that does not support all the unicode characters that a usecase requires. In such a case, try to change the font to a more compatible one. "Courier New" works mostly well, also "Arial Unicode MS" does a good job. But there is no font that covers totally everything, so maybe you will need to switch between two or three fonts to cover all required characters. For Arabic, "Arial" is a good choice, but there are many interesting alternatives.

Liferay 6.1 TextEditor Line Break Issue

I'm having issue with the Liferay6.1 TextEditor/CKEditor line breaks. It adds too much space between paragraphs. Is there any way I can change the config so that the line breaks add less space between paragraphs?
By rendering of articles you can replace the output stream of articles over the portal properties:
journal.transformer.regex.pattern.0=
journal.transformer.regex.replacement.0=
search regex what you need and put this to portal-ext.properties.
Isn't it all a matter of the css you have in your theme? You can change the line height, margins etc. in your theme to reflect the dimensions you need.
For a start, try to manipulate the css with Firebug (or whatever is the equivalent for your browser) to change the line height, then bring the changes forward to your theme

Difference between hard wrap and soft wrap?

I am in the process of writing a text editor. After looking at other text editors I have noticed that a number of them refer to a "soft" versus "hard" wrap. What is the difference? I can't seem to find the answer by searching.
A hard wrap inserts actual line breaks in the text at wrap points, with soft wrapping the actual text is still on the same line but looks like it's divided into several lines.
It's usual for text editors to auto-wrap text into paragraphs with hard newlines, but it's less common for the text to be re-flowed into a nice paragraph if you come back later and edit/add/remove words later on. (You can do this manually in emacs with M-q.)
This is rather annoying, since obsessive compulsive people like me then go back and have to manually re-insert the hard breaks at the appropriate points.
On the other hand, soft wrapping is annoying because most all command line tools use line-based diff-ing (version control is where this becomes most noticeable to me). If you've got a 1/3-page paragraph that's soft wrapped and fix a typo, it's basically impossible to see where the change is in a regular diff output or similar.
soft : The text in the textarea is not wrapped when submitted in a form. This is default
hard : The text in the textarea is wrapped (contains newlines) when submitted in a form. When "hard" is used, the cols attribute must be specified
Reference: W3Schools

Resources