Re: [BUG] Async pdf export broken with native-comp
> On Jul 15, 2021, at 10:45 AM, Sébastien Miquel > wrote: > > Hi, > > The async pdf export functionality appears to be broken with latest org and a > recent emacs version compiled with native-comp enabled (I have not tested > without native-comp). > > To reproduce: > > - use `emacs -q` and an empty init.el file (your init file gets picked up by >the async emacs instance) > - (setq org-export-async-debug t) > - find any org file and hit =C-c C-e C-a C-l C-p= to export as pdf file. > > The async process will exit abnormaly. > > The issue stems from this line in `org-export-to-file` > : (ignore-errors (funcall ',post-process ,file)) > > In `org-latex-export-to-pdf`, this `post-process` is set to > : (lambda (file) (org-latex-compile file)) > > I think native-comp compiles this lambda, which messes things up. > > As a fix, you can quote the lambda in `org-latex-export-to-pdf` > : '(lambda (file) (org-latex-compile file)) > > The same applies to other backends but I don't know if it's the right thing > to do. > > Regards, > > -- > Sébastien Miquel > > Did you post this to the Emacs list? Native-comp is in master, but not “released”. So I agree with what Tim said about it is too soon for Org to consider solutions if it happens to be an edge case that native-comp might be able to address. I use native-comp, but have not tried the async export yet. Mark
Re: [BUG] Async pdf export broken with native-comp
Sébastien Miquel writes: > Hi, > > The async pdf export functionality appears to be broken with latest org and a > recent emacs version compiled with native-comp enabled (I have not tested > without native-comp). > > To reproduce: > > - use `emacs -q` and an empty init.el file (your init file gets picked up by > the async emacs instance) > - (setq org-export-async-debug t) > - find any org file and hit =C-c C-e C-a C-l C-p= to export as pdf file. > > The async process will exit abnormaly. > > The issue stems from this line in `org-export-to-file` > : (ignore-errors (funcall ',post-process ,file)) > > In `org-latex-export-to-pdf`, this `post-process` is set to > : (lambda (file) (org-latex-compile file)) > > I think native-comp compiles this lambda, which messes things up. > > As a fix, you can quote the lambda in `org-latex-export-to-pdf` > : '(lambda (file) (org-latex-compile file)) > > The same applies to other backends but I don't know if it's the right thing to > do. > I think native comp has a way to go before we begin to worry about how to address any bugs which it may introduce/discover. While it is good to have information like this posted to the list for anyone who wants to experiment with native comp, it would be premature to apply any fixes to the org code base. -- Tim Cross
Re: org-mode export to (latex) PDF
Maxim Nikulin writes:
> In CSS it is possible to specify a list of fonts and a glyph is taken
> from the first font where it is present. Despite particular fonts have
> limited coverage, I see wide range of Unicode characters on web pages,
> that is why I am almost sure that system font libraries combine fonts.
In LuaTeX you can associate a font family to a range or a group of
characters. In a book I typesetted some time ago I used the Cardo font
to represent the characters for Private Use Area.
\newfontfamily\cardo{Cardo} % a fontspec command
\def\puatext#1{{\cardo #1}}
\begin{luacode*}
function my_pua (text)
texto = unicode.utf8.gsub ( text, "([\u{e000}-\u{f8ff}])", "\\puatext{%1}" )
return text
end
\end{luacode*}
\newcommand\activatepuatext{\directlua{luatexbase.add_to_callback
( "process_input_buffer" , my_pua , "my_pua" )}}
\AtBeginDocument{\activatepuatext}
(I add a simple substitution to the callback `process_imput_buffer'
[see: http://wiki.luatex.org/index.php/Callbacks], but these kinds of
overrides can also be do from Org using a custom filter).
Regards,
Juan Manuel
[BUG] Async pdf export broken with native-comp
Hi, The async pdf export functionality appears to be broken with latest org and a recent emacs version compiled with native-comp enabled (I have not tested without native-comp). To reproduce: - use `emacs -q` and an empty init.el file (your init file gets picked up by the async emacs instance) - (setq org-export-async-debug t) - find any org file and hit =C-c C-e C-a C-l C-p= to export as pdf file. The async process will exit abnormaly. The issue stems from this line in `org-export-to-file` : (ignore-errors (funcall ',post-process ,file)) In `org-latex-export-to-pdf`, this `post-process` is set to : (lambda (file) (org-latex-compile file)) I think native-comp compiles this lambda, which messes things up. As a fix, you can quote the lambda in `org-latex-export-to-pdf` : '(lambda (file) (org-latex-compile file)) The same applies to other backends but I don't know if it's the right thing to do. Regards, -- Sébastien Miquel
Re: org-mode export to (latex) PDF
On 15/07/2021 02:05, Stefan Nobis wrote: Maxim Nikulin writes: There are cm-super fonts for at least of 15 years. There are many tradeoffs in many aspects. No single font pleases everyone. So you want to say: Your requirements are more important/common/stylish/whatever that the requirements of other people? I hope, it is possible to make Org export to PDF working out of the box for more people. Surprisingly Unicode TeX engines besides alleviating of some limitations of earlier implementation bring new burden. I see no problem to fix support of Cyrillic in PdfTeX. I have not realized if it can be done for LuaTeX or XeTeX despite original expectation that support of Unicode means that there should be no problem for any character of any script. I started to discuss Russian because it is a language for which most of problems are apparent for me. Perhaps a similar approach can be used for other scripts. Before UTF-8 became wide spread on Linux, there were guides how to enable support of Cyrillic in e.g. Netscape Navigator. Now such problems are forgotten. Is it achievable for TeX? In CSS it is possible to specify a list of fonts and a glyph is taken from the first font where it is present. Despite particular fonts have limited coverage, I see wide range of Unicode characters on web pages, that is why I am almost sure that system font libraries combine fonts. Do Unicode TeX engines support such combination of fonts? Is it efficient enough to be used by default? Is it possible to write reasonably complete config for such purpose? It is preferable to have such config as a LaTeX style file, but it may be implemented in Org code as well. There are two quite distinct cases: documents with carefully chosen fonts (e.g. a book) and everyday notes when particular font is not so important. For the former case a glyph taken from wrong font is a serious error. For the latter one, likely even low quality font is significantly better than a missed character. I think, both cases should be supported however. [unicode-math] Thank you for the hint. Do you think Org should use it by default? Are there any caveats? Yes, unicode-math should be seen as must have for lualatex and xelatex (if math is used). As far as I know there are no downsides and it should be part of the default packages (but only for lualatex and xelatex, not for pdflatex). Maybe it is possible to scan the document for presence of character from specific category, range, etc., to avoid overhead when the package is not necessary. Is it possible to detect lualatex and xelatex in runtime? Yes, that is possible. The LaTeX package iftex provides macros to execute commands based on the running engine (see https://www.ctan.org/pkg/iftex?lang=en). I mean detection if LuaLaTeX or XeLaTeX is usable from Org code. The intention is to minimize customization required before successful export. Ideally Org should guess reasonable configuration form content of the document and available external tools (and maybe freeze it by adding properties to the document to make next compilations faster). Certainly user should have a way to force fixed values by disabling autoconfiguration as a whole or only for particular settings. Is it possible to provide reasonable defaults for fonts? I do not think so. You want Cyrillic. But what about Japanese, Chinese, Devanagari, Tamil, Arabic etc? I doubt that there exists a single font that supports all these scripts satisfactorily. I hope, single font is not necessary since other applications can show all scripts simultaneously. Of course, my example was not complete, feel free to extend it, e.g. Randomly chosen examples: "日本", "多喝水", "".
Re: help with a regexp
Thanks everyone, these are all good suggestions. I realized though the problem is that org-mode is recognizing something like [cite:@darby-2018-lonel-atoms] as a cite link because of the cite: part of it. In fact org-mode seems to recognize all [link:path] as an org link. In general that seems ok, but it leads to overlapping syntax with org-cite and the one org-ref link. It seems to be a partial solution to remove the cite link from org-link-parameters, but that isn't ideal to me because older documents won't work with org-ref that way (most of mine use cite: very extensively). The best solution in my opinion would be for org-mode to not recognize [cite:...] as a link. Other ideas? Thanks, Stephen Berman writes: > On Wed, 14 Jul 2021 20:43:24 -0400 John Kitchin > wrote: > >> Hi all, I could use a bit of help with a regexp. I am trying to fine tune >> the org-ref citation regexp to >> make it orthogonal to org-cite. >> >> I want to recognize these as org-ref links >> >> [[cite:schuett-2018-schnet]] >>cite:schuett-2018-schnet >> >> but not >> >> [cite:@schuett-2018-schnet] >> >> so either 0 or 2 [[ can prefix it to be a cite link in org-ref, but not 1 [. >> >> right now the cite: in the org-cite syntax is getting flagged as bad cite >> link which I want to avoid. >> >> is this doable? > > For your example this is sufficient (for real usage you probably want to > add more context to the right of 'cite'): > > (re-search-forward "\\[\\[cite:\\|[^[]cite:") > > Steve Berman -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu Pronouns: he/him/his
Re: org-mode export to (latex) PDF
Tim Cross writes:
> Stefan Nobis writes:
>> But maybe we could assemble a list of good (enough) fonts for
>> different languages/scripts and provide a default setup in Org for
>> LaTeX export, that sets a proper font for the chosen document
>> language?
> I think such a list would be a really good addition to worg.
I think it's a great idea. Some resources on fonts and languages that
may be useful:
- The LaTeX Font Catalogue (https://tug.org/FontCatalogue/) is pretty
complete and includes a lot of high quality fonts, with coverage for
many languages. The fonts are from diverse origins, for example the
excellent fonts for Greek and Latin alphabets from the Greek Font
Society, the TeX Gyre project fonts, etc.
- To get quick information from an otf font (otf features, Unicode
ranges, scripts, glyphs, etc.) otfinfo is very useful
(https://man.archlinux.org/man/otfinfo.1.en). But the more powerful
tool in this regard is fontforge (https://fontforge.org/en-US/), which
is not only a complete professional font editor (and free as in
freedom) but can also be used by everyone to audit all aspects from a
font: glyphs, metadata, otf features, languages, scripts, ranges, etc.
- There are specialized fonts in a wide coverage of ranges and scripts,
but many are low-quality or proprietary. Google's Noto Fonts ensure at
least a reasonably complete coverage: I use them only for experiments
(or for ensure certain "rare" scripts in Emacs buffers, as Linear B or
Gothic), but they can also be used within a document.
- Finally, in case anyone is interested, I also wrote for my personal
use a Helm source to list all system font families and insert the
family name into a LaTeX document with the syntax of fontspec or Babel
("\babelfont", which is a frontend for fontspec).
Best regards,
Juan Manuel
Re: visual-line-mode: virtual-auto-fill-mode better
>>> "a" == autofrettage writes: > Hi, > Uwe wrote: >> I am not entirely convinced by this mode and now came across >> virtual-auto-fill-mode that looks to me a much nicer solution. >> Any comments? > I haven't tried virtual-a-f-m myself, so I cannot say if it is > the ultimate solution. However, I have tried visual-fill-column- > mode together with visual-line-mode. > The tags tended to mess things up, until I started to use these settings: Right, precisely this is why I gave up this solution, so I am curious to see, how this virtual-auto-fill-mode behaves smime.p7s Description: S/MIME cryptographic signature
Re: help with a regexp
On Thu, 15 Jul 2021 10:40:40 +0200 Stephen Berman wrote: > On Wed, 14 Jul 2021 20:43:24 -0400 John Kitchin > wrote: > >> Hi all, I could use a bit of help with a regexp. I am trying to fine tune >> the org-ref citation regexp to >> make it orthogonal to org-cite. >> >> I want to recognize these as org-ref links >> >> [[cite:schuett-2018-schnet]] >>cite:schuett-2018-schnet >> >> but not >> >> [cite:@schuett-2018-schnet] >> >> so either 0 or 2 [[ can prefix it to be a cite link in org-ref, but not 1 [. >> >> right now the cite: in the org-cite syntax is getting flagged as bad cite >> link which I want to avoid. >> >> is this doable? > > For your example this is sufficient (for real usage you probably want to > add more context to the right of 'cite'): > > (re-search-forward "\\[\\[cite:\\|[^[]cite:") Or simply: (re-search-forward "\\[\\[\\|[^[]cite:") Steve Berman
Re: help with a regexp
On Wed, 14 Jul 2021 20:43:24 -0400 John Kitchin wrote: > Hi all, I could use a bit of help with a regexp. I am trying to fine tune the > org-ref citation regexp to > make it orthogonal to org-cite. > > I want to recognize these as org-ref links > > [[cite:schuett-2018-schnet]] >cite:schuett-2018-schnet > > but not > > [cite:@schuett-2018-schnet] > > so either 0 or 2 [[ can prefix it to be a cite link in org-ref, but not 1 [. > > right now the cite: in the org-cite syntax is getting flagged as bad cite > link which I want to avoid. > > is this doable? For your example this is sufficient (for real usage you probably want to add more context to the right of 'cite'): (re-search-forward "\\[\\[cite:\\|[^[]cite:") Steve Berman
Re: help with a regexp
> On Jul 15, 2021, at 13:41, Timothy wrote:
>
>
> Hi John,
>
> John Kitchin writes:
>
>> Hi all, I could use a bit of help with a regexp. I am trying to fine tune
>> the org-ref citation regexp to make it orthogonal to org-cite.
>>
>> I want to recognize these as org-ref links
>>
>> [[cite:schuett-2018-schnet]]
>> cite:schuett-2018-schnet
>>
>> but not
>>
>> [cite:@schuett-2018-schnet]
>>
>> so either 0 or 2 [[ can prefix it to be a cite link in org-ref, but not 1 [.
>>
>> right now the cite: in the org-cite syntax is getting flagged as bad cite
>> link which I want to avoid.
>>
>> is this doable?
>
> I'd think so. Let me know if https://regex101.com/r/Ud6HVY/1 helps :)
cite:[^@][A-Za-z0-9_-]+|\[\[cite:[^@][A-Za-z0-9_-]+\]\]
There are no reasons to limit the string after : to ascii.
in isearch I tried:
\[\{2\}cite.*\]\{2\}\|[^\[]cite:[^ \
]*
And it seems to do the job.
--
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/
