I am creating an Index document using Asciidoctor which enlists all my subsequent collection of documents. The output that is generated lists the indexes on top of the main content at the center of the page.
I visited
Asciidoctor User Manual and tried using :toc: left to move the index to the left, but the said thing didn't happen. It still renders the index at the top of the main content and not to the left of the main content.
How should I move further?
Help much appreciated
Thanks in advance!
The attribute toc: left was overridden by the Gradle script which was used to build it. Everytime the value at compilation was overridden to toc: '' to an empty string, which by default renders it in the center of the page. Hence it wasn't working.
Solution:
Removed the dependency, and now it works. :)
Related
The Setup
Currently, CKEditor 5 does not support image captions for inline images. As our CMS needs to utilize both block and inline images, I wrote a plugin that extends schema and conversions with a custom <caption> element that works both for <imageInline> and <imageBlock> (and a custom, plaintext-only <alt> element for also have a nested editable for the image alternative text, but that's omitted here because it's not part of the issue).
It starts with a schema extension for <caption> to work for both image types:
schema.register('caption', {
allowIn: ['imageBlock', 'imageInline'],
allowContentOf: '$block',
isLimit: true
});
Then, several conversions and up-/downcast helpers from the original image packages #ckeditor/ckeditor5-image/... (image/imageblockediting.js, image/imageinlineediting.js, image/converters.js, image/utils.js, imagecaption/imagecaptionediting.js) are adapted and/or overwritten with higher priority custom versions to have an editable <caption> element both inside <imageBlock> and <imageInline>.
Both image types can have a linkHref attribute, which is implemented by extended, higher priority versions of upcastImageLink() and downcastImageLink() from #ckeditor/ckeditor5-link/src/linkimageediting.js.
Also, we need to backup and restore the <caption> element and all its child nodes when changing between block and inline images by listening to the imageStyleCommand, because the command itself obviously does not care for our custom <caption> structure (the caption should be visible all the time, so there is no need for a toggle as in the original caption package).
All in all, it's 400+ lines of code, so I won't post it here - you can get the idea by looking at the original code mentioned above.
Working Code
Now, for block images we have the same model/view structure and functionality as the original <imageBlock> version, and for <imageInline> the model looks like this (including the parent paragraph and some text; please ignore the <altContainer> structure):
Which gets converted to this view structure (again, ignore the <altcontainer> structure):
The Problem
When selecting an <inlineImage> and adding a link, the linkHref attribute is not only set on the <inlineImage> element itself (that's what we want), but also on all of the <caption>'s child nodes. So the model is looking like this:
And the view:
As you can see, the linked text from the original caption gets lost, too.
So how do you prevent this?
I'm assuming this is happening because <imageInline> is obviously registered as isInline:true, because when linking an <imageBlock> image this is not an issue! I've tried to fix this with a registerPostFixer() routine, but that can fix only parts of the problem.
I'm working around this problem now by cloning the whole <caption> structure before linking an image, and replacing the "buggy" version with the cloned one after the link command has finished.
There should be a more elegant way to tell the engine not to apply the linkHref attribute to the <caption> child nodes, and leaving existing linkHref attributes inside as is; which is also an issue when removing the link for the image: existing child linkHref attributes get also removed.
I'd like to add a simple warning directive at the top of every page on a Sphinx RTD site:
.. attention::
The next major release of this project will launch on X date.
In the meantime, we're looking for feedback.
If you'd like an early preview, please reach out at someemail#someaddress.com!
What's the simplest way to do this? I'm using the sphinx_rtd_theme.
I can see how to add a block using the extrabody block, but it appears outside the main content area and is positioned and styled totally independently.
Ideally, I'd want this block to show up at an attention directive just below the breadcrumbs on every page.
You could add this to the conf.py Sphinx configuration file:
rst_prolog = """.. attention::
The next major release is imminent.
"""
and it will be included at the beginning of every source file that is read ‒ see https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-rst_prolog.
F-string literals work too, so f'This is release #{release}' will substitute that variable value.
I'm using the readthedocs theme for a personal sphinx documentation project. Everything works fine except the display of the left frame of the content list: It display all level of section headings, without showing any hierarchy. How to let it show levels as in most readthedocs documentation project?
After click the + sign, it looks right:
This is how I mark the section title:
Apache
======
How to restart
--------------
This sounds like this bug: Toc not expanding.
If not, please include your version of Sphinx, where you build the docs, and whether what you do to build the docs satisfies the conditions of that issue.
Otherwise, there is no configurable option to expand all options in the for the RTD Sphinx theme. See https://sphinx-rtd-theme.readthedocs.io/en/latest/configuring.html#toc-options You will have to write custom JavaScript to make it so, and include the static asset with the theme. That homework is left to the questioner or a gracious answerer.
You could also file a feature request at https://github.com/rtfd/sphinx_rtd_theme/issues/new
This is the default behavior of sphinx. The section that you select expands on the left side bar. Else, it remains collapsed. https://docs.readthedocs.io/en/latest/versions.html this link also shows similar kind of behavior. To make it collapsible on clicking, you will require to update the theme.
I need to change the position of div in my magento page
Discount Code should be placed to the left, Middle Shipping Estimation
Based on you selection should come at the bottom horizontally.
You need to find the exact html page what you need to change. But according to the template the file location may change. You can find the location by going to
system ->configuration ->Developer(left bottom) then select Main Web site from the current configuration(left top)
Then you can select YES for the Template Path Hints in the Debug section. with that you will be able to see the file location in your root.
After that you change the div location as you need :)
For some reason when somebody performs a search on my site the search results do not display underneath the search box, they appear on the far left of the screen.
Any ideas of what file this would be configured in?
Let me correct myself it's not the search results but the search suggestions
I can't offer a direct solution to your problem, but turning on template hints might point you in the right direction. In the Admin, go to System > Configuration, Select your store view from the scope drop down at the top left. Unless you're running multi-store, or have changed the name of the default store it'll be called "Default Store View". Then scroll down to "Developer" and open up the "Debug" section. Turn on both Template Path Hints" and "Add Block Names to Hints". This will add a div with a red border around each template in your layout and a heading which includes the name of the template. It will liklely completely screw up your page layout, but will show you which template generated every tag on the page and help you track down the issue.
The DeveloperToolbar extension makes turning this on/off quickly much easier, but I wouldn't recommend deploying it to a production site.
Alan Storm's indispensable CommerceBug is another tool which is very handly for tracking down front end issues. CommerdeBug can show you the layout handles and the aggregate layout XML used to generate the current page. Both of which are useful for determing why a specific block was (or wasn't) included.
So in case anybody else runs into this or wants to move where their search suggestions display it is in styles.css under .searchautocomplete.