On page save the image paths are modified which is causing the image path to fail. There should be a \ between _webedit and cached-images and the \ with first digit of the image file name is being modified.
How can I prevent this and which files do I need to modify?
Input
<img src="http://www.domain.co.uk/_webedit\cached-images\21-0-
0-617-10000-7488-767.jpg"
srcset="http://www.domain.co.uk/_webedit\cached-images\21-0-0-
617-10000-7488-1920.jpg
1920w,http://www.domain.co.uk/_webedit\cached-images\21-0-0-
617-10000-7488-256.jpg
256w,http://www.domain.co.uk/_webedit\cached-images\21-0-0-617-
10000-7488-512.jpg
512w,http://www.domain.co.uk/_webedit\cached-images\21-0-0-617-
10000-7488-768.jpg
768w,http://www.domain.co.uk/_webedit\cached-images\21-0-0-617-
10000-7488-1024.jpg
1024w,http://www.domain.co.uk/_webedit\cached-images\21-0-0-
617-10000-7488-1280.jpg
1280w,http://www.domain.co.uk/_webedit\cached-images\21-0-0-
617-10000-7488-1536.jpg
1536w,http://www.domain.co.uk/_webedit\cached-images\21-0-0-
617-10000-7488-1792.jpg
1792w,http://www.domain.co.uk/_webedit\cached-images\21-0-0-
617-10000-7488-566.jpg
566w,http://www.domain.co.uk/_webedit\cached-images\21-0-0-617-
10000-7488-1132.jpg
1132w,http://www.domain.co.uk/_webedit\cached-images\21-0-0-
617-10000-7488-1698.jpg 1698w" sizes="(max-width:383px) 100vw,(min-
width:384px) and (max-width:575px) 100vw,(min-width:576px) and (max-
width:767px) 100vw,(min-width:768px) and (max-width:959px) calc(50.26vw
- 12px),(min-width:960px) and (max-width:1152px) calc(50vw -
10px),566px" alt="Soak up the sun in our relaxing garden" data-aspect-
ratio="0.5000">
Output
<img alt="Soak up the sun in our relaxing garden" data-aspect-
ratio="0.5000" sizes="(max-width:383px) 100vw,(min-width:384px) and
(max-width:575px) 100vw,(min-width:576px) and (max-width:767px) 100vw,
(min-width:768px) and (max-width:959px) calc(50.26vw - 12px),(min-
width:960px) and (max-width:1152px) calc(50vw - 10px),566px"
src="http://www.domain.co.uk/_webeditcached-images-0-0-617-
10000-7488-767.jpg"
srcset="http://www.domain.co.uk/_webeditcached-images-0-0-617-
10000-7488-1920.jpg
1920w,http://www.domain.co.uk/_webeditcached-images-0-0-617-
10000-7488-256.jpg 256w,http://www.domain.co.uk/_webeditcached-
images-0-0-617-10000-7488-512.jpg
512w,http://www.domain.co.uk/_webeditcached-images-0-0-617-
10000-7488-768.jpg 768w,http://www.domain.co.uk/_webeditcached-
images-0-0-617-10000-7488-1024.jpg
1024w,http://www.domain.co.uk/_webeditcached-images-0-0-617-
10000-7488-1280.jpg
1280w,http://www.domain.co.uk/_webeditcached-images-0-0-617-
10000-7488-1536.jpg
1536w,http://www.domain.co.uk/_webeditcached-images-0-0-617-
10000-7488-1792.jpg
1792w,http://www.domain.co.uk/_webeditcached-images-0-0-617-
10000-7488-566.jpg 566w,http://www.domain.co.uk/_webeditcached-
images-0-0-617-10000-7488-1132.jpg
1132w,http://www.domain.co.uk/_webeditcached-images-0-0-617-
10000-7488-1698.jpg 1698w" />
\ is a special character in many coding stuff indicating special treatment for the next character. Thus the editor is trying to interpret \c and that results in just a c.
If \ is just because you're using folder notation for Windows, / should work fine instead, and what is commonly used. If this fails you can force a backslash by adding a \ to every single one. Thus
_webedit\\cached
and \\ will interpret as \. I'm pretty sure though / will work and is much more advised.
CKEditor is JavaScript application and has no influence on saving data. If you can switch to Source mode and back without URL being changed then this is not editor fault and you need to look for the problem in your server-side code.
Related
I need to include the following code in a .tex file that is generated from a custom template via RMarkdown, in order to get rid of an error. However, if I try it as below in the YAML heading:
header-includes:
\newenvironment{CSLReferences}%
{}%
{\par}
it gets parsed into the .tex file as single line, like \newenvironment{CSLReferences}% {}% {\par}, thus commenting out everything after %. So how can I change the YAML part so that it correctly gets interpreted as 3 different lines?
Instead of worrying about the markdown parsing, you can write the command in a single line:
header-includes:
\newenvironment{CSLReferences}{}{\par}
Alternatively avoid all these annoying problems with markdown parsing and put your definition in a .tex file which you can include via
includes:
in_header: header.tex
After some trials & searching this works (found a solution while writing the question):
header-includes:
- "\\newenvironment{CSLReferences}%"
- "{}%"
- "{\\par}"
Interestingly, I couldn't find much in the official documentation.
EDIT:
As #samcarter mentioned in the comments & an answer, in this particular case a single line would've been enough, as
header-includes:
\newenvironment{CSLReferences}{}{\par}
(OS is Windows 7 Professional. jq is version 1.5.)
I've been using jq to automate prettifying some JSON files (with Python). It seems to me after some time trying to determine why it wasn't working that jq fails silently when working with a file path string that's length 28, or simply stops working if the file path string is length 29 or more.
E.g. on cmd (and it's worth pointing out that I made a kind of shortcut so that jq calls jq-win64.exe, and tested the latter directly as well, so that's not the source of the issue):
C:\jq>jq . 123456789012345678901234567
displays prettified content of the file;
C:\jq>jq . 1234567890123456789012345678
displays nothing; and
C:\jq>jq . 12345678901234567890123456789
causes a "jq-win64.exe has stopped working" window.
(I also tested this on JSON files within folders; the common point was that the input string be of length 28 or more including slashes to fail.)
Is this a bug? If it's not, what can I do to work around it Okay, I admit that was a stupid question, I can work around it by copying content into a temp file in the base folder, prettify it, and then save it back to wherever I want it to be. More on-point question: is this the best workaround available for me to take?
There was a Windows-specific bug in jq 1.5 (see e.g. https://github.com/stedolan/jq/issues/1094). It was fixed shortly after the release of jq 1.5.
To obtain a post-1.5 .exe for Windows, see any of:
https://chocolatey.org/packages?q=jq
https://stedolan.github.io/jq/download
https://github.com/stedolan/jq/wiki/Installation#windows-using-appveyor
I am using Mac and
\usepackage{natbib}
It seems that the space in the path caused problems, i.e. Box Sync.
\bibliography{/Users/c082213/Box Sync/AA_My_Papers/MyStats.bib}
I have tried to put them in double "", and it doesn't work on Mac. Is there anyway that we can fix this?
Many thanks!
one solution is to use a relative path.
If the .bib and the .tex file are in the same folder you can just write:
\bibliography{MyStats}
On the other hand, there are many other possible solutions to handle the problem with with spaces in the path. My suggestion is: avoid it to name folders or files with spaces. It will produce problems for some reasons.
I had the same issue with Box and it's default usage of spaces, so I created a soft link having no spaces:
ln -s "Box Sync" Boxsync
then I can use the bibliography command as usual.
Okay so here is what I want to do. I want to add a print option that prints whatever the user's document is to a PDF and adds some headers before sending it off to a device.
I guess my questions are: how do I add a virtual "printer" driver for the user that will launch the application I've been developing that will make the PDF (or make the PDF and launch my application with references to the newly generated PDF)? How do I interface with CUPS to generate the PDF? I'm not sure I'm being clear, so let me know if more information would be helpful.
I've worked through this printing with CUPS tutorial and seem to get everything set up okay, but the file never seems to appear in the appropriate temporary location. And if anyone is looking for a user-end PDF-printer, this cups-pdf-for-mac-os-x is one that works through the installer, however I have the same issue of no file appearing in the indicated directory when I download the source and follow the instructions in the readme. If anyone can get either of these to work on a mac through the terminal, please let me know step-by-step how you did it.
The way to go is this:
Set up a print queue with any driver you like. But I recommend to use a PostScript driver/PPD. (A PostScript PPD is one which does not contain any *cupsFilter: ... line.):
Initially, use the (educational) CUPS backend named 2dir. That one can be copied from this website: KDE Printing Developer Tools Wiki. Make sure when copying that you get the line endings right (Unix-like).
Commandline to set up the initial queue:
lpadmin \
-p pdfqueue \
-v 2dir:/tmp/pdfqueue \
-E \
-P /path/to/postscript-printer.ppd
The 2dir backend now will write all output to directory /tmp/pdfqueue/ and it will use a uniq name for each job. Each result should for now be a PostScript file. (with none of the modifications you want yet).
Locate the PPD used by this queue in /etc/cups/ppd/ (its name should be pdfqueue.ppd).
Add the following line (best, near the top of the PPD):
*cupsFilter: "application/pdf 0 -" (Make sure the *cupsFilter starts at the very beginning of the line.) This line tells cupsd to auto-setup a filtering chain that produces PDF and then call the last filter named '-' before it sends the file via a backend to a printer. That '-' filter is a special one: it does nothing, it is a passthrough filter.
Re-start the CUPS scheduler:sudo launchctl unload /System/Library/LaunchDaemons/org.cups.cupsd.plist
sudo launchctl load /System/Library/LaunchDaemons/org.cups.cupsd.plist
From now on your pdfqueue will cause each job printed to it to end up as PDF in /tmp/pdfqueue/*.pdf.
Study the 2dir backend script. It's simple Bash, and reasonably well commented.
Modify the 2dir in a way that adds your desired modifications to your PDF before saving on the result in /tmp/pdfqueue/*.pdf...
Update: Looks like I forgot 2 quotes in my originally prescribed *cupsFilter: ... line above. Sorry!
I really wish I could accept two answers because I don't think I could have done this without all of #Kurt Pfeifle 's help for Mac specifics and just understanding printer drivers and locations of files. But here's what I did:
Download the source code from codepoet cups-pdf-for-mac-os-x. (For non-macs, you can look at http://www.cups-pdf.de/) The readme is greatly detailed and if you read all of the instructions carefully, it will work, however I had a little trouble getting all the pieces, so I will outline exactly what I did in the hopes of saving someone else some trouble. For this, the directory with the source code is called "cups-pdfdownloaddir".
Compile cups-pdf.c contained in the src folder as the readme specifies:
gcc -09 -s -lcups -o cups-pdf cups-pdf.c
There may be a warning: ld: warning: option -s is obsolete and being ignored, but this posed no issue for me. Copy the binary into /usr/libexec/cups/backend. You will likely have to the sudo command, which will prompt you for your password. For example:
sudo cp /cups-pdfdownloaddir/src/cups-pdf /usr/libexec/cups/backend
Also, don't forget to change the permissions on this file--it needs root permissions (700) which can be changed with the following after moving cupd-pdf into the backend directory:
sudo chmod 700 /usr/libexec/cups/backend/cups-pdf
Edit the file contained in /cups-pdfdownloaddir/extra/cups-pdf.conf. Under the "PDF Conversion Settings" header, find a line under the GhostScript that reads #GhostScript /usr/bin/gs. I did not uncomment it in case I needed it, but simply added beneath it the line Ghostscript /usr/bin/pstopdf. (There should be no pre-cursor # for any of these modifications)
Find the line under GSCall that reads #GSCall %s -q -dCompatibilityLevel=%s -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile="%s" -dAutoRotatePage\
s=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c .setpdfwrite \
-f %s Again without uncommenting this, under this I added the line GSCall %s %s -o %s %s
Find the line under PDFVer that reads #PDFVer 1.4 and change it to PDFVer, no spaces or following characters.
Now save and exit editing before copying this file to /etc/cups with the following command
sudo cp cups-pdfdownloaddir/extra/cups-pdf.conf /etc/cups
Be careful of editing in a text editor because newlines in UNIX and Mac environments are different and can potentially ruin scripts. You can always use a perl command to remove them, but I'm paranoid and prefer not to deal with it in the first place.
You should now be able to open a program (e.g. Word, Excel, ...) and select File >> Print and find an available printer called CUPS-PDF. Print to this printer, and you should find your pdfs in /var/spool/cups-pdf/yourusername/ by default.
*Also, I figured this might be helpful because it helped me: if something gets screwed up in following these directions and you need to start over/get rid of it, in order to remove the driver you need to (1) remove the cups-pdf backend from /usr/libexec/cups/backend (2) remove the cups-pdf.conf from /etc/cups/ (3) Go into System Preferences >> Print & Fax and delete the CUPS-PDF printer.
This is how I successfully set up a pdf backend/filter for myself, however there are more details, and other information on customization contained in the readme file. Hope this helps someone else!
I'm using Vim with a bunch of plugins (pathogen, ctags, snipmate, supertab, ...), and everything works fine for all kinds of file extensions.
However, when I'm try to edit .tex files it presents two problems which seem related. First, Vim starts to work really slow, and second, when I press "any letter + Tab", it tries to auto-complete with words previously written in the text.
One way which I tried to solve those issues, is by removing the supertab plugin from my bundle folder, but it's a not satisfactory solution.
The problem is due to the relativenumber option, when I turned it off the latex edit speed come back to normal.
The following relativenumber, cursorline and MatchParen can slow vim down a lot, especially when dealing with large latex files. When I turn them off then vim becomes much more responsive when dealing with large latex files.
To turn off relative number, type the following in editor mode:
:set nornu
To turn off cursorline, type the following in editor mode:
:set nocursorline
To turn off MatchParen, type the following in editor mode:
:NoMatchParen
If you still want regular line numbering then you can have
:set number
For a more permanent solution, you can also set latex specific settings in your ~/.vimrc file:
" Latex specification
au BufNewFile,BufRead *.tex
\ set nocursorline |
\ set nornu |
\ set number |
\ let g:loaded_matchparen=1 |
The \ and the | are there to allow you add the latex commands over multiple lines.
The other two possible problems are the following being active
cursorline
DoMatchParen
So to make your LᴬTᴇX editing experience much better, you can do something like the following in your ~/.vimrc
au FileType tex setlocal nocursorline
au FileType tex :NoMatchParen
After doing this my Vim is as fast with .tex files as it is with .cpp ones.
I know this is an old issue, but, to anyone seeing this now, it is better to use the ftplugin/ folder in your .vim directory to instruct Vim to enable certain options on a specific file type. Create a file ~/.vim/ftplugin/tex.vim with the following options:
set nocursorline
set nornu
let g:loaded_matchparen=1
This makes Vim load these options only on TeX files (*.tex and related) without resorting to an :autocommand like gloriphobia’s answer does.
Folding is another common source of slowdown. It is normally disabled by default, but perhaps you have enabled it. You can just disable it again:
" (1) if you use the builtin TeX support:
" comment the line in your vimrc that looks like this:
"let g:tex_fold_enabled = ...
" OR, just to be sure, do:
unlet! g:tex_fold_enabled
" (2) if you rather use VimTeX:
" comment the line in your vimrc that looks like this:
"let g:vimtex_fold_enabled = 1
" OR, just to be sure, do:
let g:vimtex_fold_enabled = 0
Note that folding must be enabled/disabled before TeX syntax is loaded in the buffer. Also, Vim option 'foldenable' (toggled by the normal-mode command zi) does not actually clear folding, it just hides it but it’s still there).
However, if you don’t want to give up on folding altogether, I found a single bottleneck in the builtin TeX folding that was responsible for most of the slowdown in my case: the document environment. Simple test: typing stuff just before \begin{document} is reasonably fast, but typing right after it is amazingly laggy. I guess it happens because that environment commonly spans hundreds of lines.
If you use the builtin TeX folding, you can prevent the folding of just the document environment by disabling the texDocZone matchgroup¹. Anyway, why would you want to fold the toplevel contents?
" put this in your vimrc :
au FileType tex :syntax clear texDocZone
" OR put this in ~/.vim/after/syntax/tex.vim :
syntax clear texDocZone
Alternatively, if you have VimTeX, you can replace the builtin TeX folding with the VimTeX’ one. I find it generally better, and it carefully avoids folding the document environment.
" put this in your vimrc :
unlet! g:tex_fold_enabled " just to be sure
let g:vimtex_fold_enabled = 1
VimTeX’ folding is nicely customizable, see :help vimtex-folding.
¹ As of version 121 (April 2022) of the builtin TeX syntax.