Re: Bug: Unable to resolve link when exporting subtree [9.4.6 (9.4.6-10-gee652a-elpaplus @ /home/kun/.emacs.d/elpa/org-plus-contrib-20210712/)]
Kun Liu writes: > I see error > user-error: Unable to resolve link: "*B" This is expected default behaviour. You can customise it using org-export-with-broken-links. Best, Ihor
Re: Comments break up a paragraph when writing one-setence-per-line
on the other hand, if it were fixed, it would possibly make par sep blank lines be more controllable in such exporters as ascii. On 7/16/21, Kaushal Modi wrote: > Hello, > > > On Fri, Jul 16, 2021 at 12:35 PM Bruce D'Arcus wrote: > >> On Fri, Jul 16, 2021 at 12:07 PM William Denton wrote: >> >> > However, I was a bit surprised when I found that a commented line >> > starts >> a new >> > paragraph. >> >> I hadn't yet discovered that, but I think it should be considered a >> bug. > > > Comments causing paragraph breaks has been a long known behavior. I learned > about it few years back, probably from one of the threads here or by > reading the code. > > >> The output of your example should remove the commented line >> entirely, and so be: >> >> In this paragraph I introduce an idea. >> But I am sure about this. And here is my conclusion. >> >> Perhaps it can be easily fixed? >> > > I don't think it would be a very easy fix as the behavior stems from an > intentional low level implementation in org-element.el. Changing this > behavior will cause a regression in all Org exporters out there. > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: oc-csl/citeproc: suffixes in cite links
Ah, that's so immensely helpful. Thank you, this will be very good to know. On Fri, Jul 16, 2021 at 5:21 PM András Simonyi wrote: > Dear Matt, > > yes, oc-csl has to extract the locator information from the suffix > because CSL processors like citeproc-el work with structured locator > data. To help this extraction, ocl-csl (similarly to citeproc-org and > I think pandoc) defines a list of locator expressions to be used in > the suffix (see the commentary of oc-csl or the citeproc-org README), > for chapter one can currently use "chap.", "chaps." or "chapter" -- > hopefully replacing the citation with > [cite:@GentilcoreTastetomatoItaly2009 chap. 4] will fix the rendering, > > best regards, > András > > On Fri, 16 Jul 2021 at 22:40, Matt Price wrote: > > > > (cc:ing Andras in case this issue maybe comes from citeproc) > > > > I'm having some trouble with suffixes in cite: links when the oc-csl > exporter is enabled, e.g. with something like this: > > > > #+cite_export: csl "/home/matt/src/styles/apa.csl" > > > > this cite: > > [cite:@GentilcoreTastetomatoItaly2009 ch4] > > > > is rendered as: > > > > (ch Gentilcore, 2009, p. 4) > > > > > > on export to HTML (in a document with no print_bibliography directive). > > > > BY contrast, ob-basic gives: > > > > (Gentilcore, David, 2009 ch4) > > > > Is oc-csl doing some extra work to process suffix, or is this likely an > issue with citeproc, or alternatively am I just not really understanding > what ought to be happening? > > > > > > Also, are other people seeing this same issue? I don't have a testing > setup that would allow me to easily run emacs -Q (given how much has to be > imported) so ... well, so, my apologies for not having done that. > > > > > > THanks, > > > > Matt > > > > >
Re: oc-csl/citeproc: suffixes in cite links
Dear Matt, yes, oc-csl has to extract the locator information from the suffix because CSL processors like citeproc-el work with structured locator data. To help this extraction, ocl-csl (similarly to citeproc-org and I think pandoc) defines a list of locator expressions to be used in the suffix (see the commentary of oc-csl or the citeproc-org README), for chapter one can currently use "chap.", "chaps." or "chapter" -- hopefully replacing the citation with [cite:@GentilcoreTastetomatoItaly2009 chap. 4] will fix the rendering, best regards, András On Fri, 16 Jul 2021 at 22:40, Matt Price wrote: > > (cc:ing Andras in case this issue maybe comes from citeproc) > > I'm having some trouble with suffixes in cite: links when the oc-csl exporter > is enabled, e.g. with something like this: > > #+cite_export: csl "/home/matt/src/styles/apa.csl" > > this cite: > [cite:@GentilcoreTastetomatoItaly2009 ch4] > > is rendered as: > > (ch Gentilcore, 2009, p. 4) > > > on export to HTML (in a document with no print_bibliography directive). > > BY contrast, ob-basic gives: > > (Gentilcore, David, 2009 ch4) > > Is oc-csl doing some extra work to process suffix, or is this likely an issue > with citeproc, or alternatively am I just not really understanding what ought > to be happening? > > > Also, are other people seeing this same issue? I don't have a testing setup > that would allow me to easily run emacs -Q (given how much has to be > imported) so ... well, so, my apologies for not having done that. > > > THanks, > > Matt > >
oc-csl/citeproc: suffixes in cite links
(cc:ing Andras in case this issue maybe comes from citeproc) I'm having some trouble with suffixes in cite: links when the oc-csl exporter is enabled, e.g. with something like this: #+cite_export: csl "/home/matt/src/styles/apa.csl" this cite: [cite:@GentilcoreTastetomatoItaly2009 ch4] is rendered as: (ch Gentilcore, 2009, p. 4) on export to HTML (in a document with no print_bibliography directive). BY contrast, ob-basic gives: (Gentilcore, David, 2009 ch4) Is oc-csl doing some extra work to process suffix, or is this likely an issue with citeproc, or alternatively am I just not really understanding what ought to be happening? Also, are other people seeing this same issue? I don't have a testing setup that would allow me to easily run emacs -Q (given how much has to be imported) so ... well, so, my apologies for not having done that. THanks, Matt
Re: could we support * in a cite style.
BTW, Nicolas added a helpful function towards the end, which returns both the full style and variant and names, and also the shortcuts. (org-cite-supported-styles '(natbib biblatex))
Re: org-mode export to (latex) PDF
Maxim Nikulin writes: > I think that low level implementation in browser or in some underlying > library is much faster > > > LM Roman 12 > abc абв…с > LM Roman 12, CMU Serif > abc абв…с > They are two different scenarios: web publishing and book typesetting (Donald Knuth in the TexBook refers to TeX as: "...a new typesetting system intended for the creation of beautiful books [...] you will be telling a computer exactly how the manuscript is to be transformed into pages whose typographic quality is comparable to that of the world's finest printers"). LuaTeX, like the rest of TeX engines, is a highly refined typesetting system, the digital evolution of the mechanical printing press and the art of typographers. Its goal is printing press instead of web browsers. All decisions regarding the chosen typefaces should be taken before. When I prepare a book design, all those decisions I take them before, and it takes time to test and calibrate typefaces: choose the font family, or font family groups for certain languages. Mixing fonts is not trivial for professional typography. This is not the scenario you describe, nor is it necessary to ensure readability in multiple browsers with "fallback fonts" for missed glyphs. In TeX ecosystem it makes no sense (it can be done, anyway[1]) to add fallback fonts to ensure all characters are rendered by their corresponding glyphs. I insist: they are two orthogonal scenarios and two diametrically opposed design concepts. If the font I want to use lacks certain glyphs, I can take various decisions, depending on the glyphs I need. If I lack only certain diacritics, often with some Lua code it is enough for me (some Lua is also usually useful to adjust the position of combining diacritical marks without editing the font with fontforge and add a 'mark' or 'marktomark' tag). But, generally, if a font doesn't have the glyphs I need, I just don't use it. The same is true in the case of small caps. If a font does not have small caps, you should never use those horrible and illegible synthesized small caps from DTP programs ... In LuaTeX and XeTeX you can define at high level, for example, your own hybrid font families. If I want to use the GFS Porson as italics from another font, a Didot typeface for example, I can do this: \newfontfamily\mygreek{GFS Didot Classic} [Script=Greek,ItalicFont=GFS Porson,ItalicFeatures={Scale=.90}] \emfontdeclare{\itshape,\upshape} \mygreek γίγνονται παῖδες δύο, \emph{πρεσβύτερος} μὲν Ἀρταξέρξης [1] If you want to have fallback fonts, you can also do it in LuaTeX by adding some Lua code: https://tex.stackexchange.com/questions/514940/define-fallback-font-for-missing-glyphs-in-lualatex (anyway, I insist that combining glyphs is something you must be done with care) Best regards, Juan Manuel
Re: could we support * in a cite style.
On Fri, Jul 16, 2021 at 2:15 PM John Kitchin wrote: > > Hi all, > It looks like this is not a supported style for the new cite syntax: > > [cite/author*:@swain-2016-chemd] > > I think it should be allowed, because it maps cleanly to the natbib cite type > of \citeauthor*. There are a bunch of other starred types as well. that would > be nicer than something like [cite/author/star:@swain-2016-chemd] or > [cite/author-star:@swain-2016-chemd] IMO. Are you aware can do this now, which will output consistent formatting across natbib and biblatex export processors, and I expect in the future too csl: [cite/a/f:@low2001] Bruce
could we support * in a cite style.
Hi all, It looks like this is not a supported style for the new cite syntax: [cite/author*:@swain-2016-chemd] I think it should be allowed, because it maps cleanly to the natbib cite type of \citeauthor*. There are a bunch of other starred types as well. that would be nicer than something like [cite/author/star:@swain-2016-chemd] or [cite/author-star:@swain-2016-chemd] IMO. John --- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: Comments break up a paragraph when writing one-setence-per-line
Hello, On Fri, Jul 16, 2021 at 12:35 PM Bruce D'Arcus wrote: > On Fri, Jul 16, 2021 at 12:07 PM William Denton wrote: > > > However, I was a bit surprised when I found that a commented line starts > a new > > paragraph. > > I hadn't yet discovered that, but I think it should be considered a > bug. Comments causing paragraph breaks has been a long known behavior. I learned about it few years back, probably from one of the threads here or by reading the code. > The output of your example should remove the commented line > entirely, and so be: > > In this paragraph I introduce an idea. > But I am sure about this. And here is my conclusion. > > Perhaps it can be easily fixed? > I don't think it would be a very easy fix as the behavior stems from an intentional low level implementation in org-element.el. Changing this behavior will cause a regression in all Org exporters out there.
Re: org-mode export to (latex) PDF
On 16/07/2021 02:40, Juan Manuel Macías wrote: 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. texto = unicode.utf8.gsub ( text, "([\u{e000}-\u{f8ff}])", "\\puatext{%1}" ) I expect it is terribly inefficient for long spans of text in particular language. Command should not be per-character, preferably per-paragraph or at least per-word "([\u{e000}-\u{f8ff}]+)" However maybe you just do not use sequences of symbols from private use area. I think that low level implementation in browser or in some underlying library is much faster LM Roman 12 abc абв…с LM Roman 12, CMU Serif abc абв…с
Re: Comments break up a paragraph when writing one-setence-per-line
On Fri, Jul 16, 2021 at 12:07 PM William Denton wrote: > However, I was a bit surprised when I found that a commented line starts a new > paragraph. I hadn't yet discovered that, but I think it should be considered a bug. The output of your example should remove the commented line entirely, and so be: In this paragraph I introduce an idea. But I am sure about this. And here is my conclusion. Perhaps it can be easily fixed? Bruce
Comments break up a paragraph when writing one-setence-per-line
I'm writing an article and decided to try putting each sentence on a different line, which I've seen some people here recommend because it makes using version control easier. It took a little while to get used to it, but I think I like it. However, I was a bit surprised when I found that a commented line starts a new paragraph. For example, let's say I have a paragraph but I want to comment out a sentence because I'm not sure if I want it in. #+begin_src org In this paragraph I introduce an idea. # Here is something I'm not sure about yet. But I am sure about this. And here is my conclusion. #+end_src org When this is exported, it becomes two paragraphs, as though the commented line was a blank line. This was unexpected, because to me this is one paragraph with one sentence hidden. People who write one-sentence-per-line, have you had this problem, and if so how did you handle it? Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
likely re-order date problem solution
I think I figured out how to make re-order dates work in orgmode. The start date is the date when items start getting used. So subtract the number of weeks before the next order is needed from the start date and write that time stamp in with a + repeater value to cover the days until the next order. You get back your start date with a repeater. So copy that time stamp down and so long as the repeater continues to work you should get a series of dates matching your re-order date requirements. There may be an easier way to do this in orgmode but I haven't run across that one yet.
Re: org-mode export to (latex) PDF
Jean-Christophe Helary writes: > Since org uses Latex to achieve export to PDF, which is quite a > common demand nowadays, something that normal org users can > understand should be posted somewhere. I second that! I just wanted to try to lower the expectation that (most) scripts will work out of the box without any kind of manual configuration. -- Until the next mail..., Stefan.
Re: org-mode export to (latex) PDF
> On Jul 16, 2021, at 18:20, Stefan Nobis wrote: > > The last glyph ("TELEPHONE RECEIVER") is not visible for me. Remember, > that Unicode gets expanded quite often and it is not easy for font > developers to keep up. I still think that the expectation, that Org > and/or LaTeX will support the whole Unicode range out of the box is a > little bit too far fetched. If I may insist, my original question was about a "good enough" *or* easily understandable setting for org export to PDF. I *never* suggested that I, or someone, expected org to support the *whole Unicode range* at any moment. Since org uses Latex to achieve export to PDF, which is quite a common demand nowadays, something that normal org users can understand should be posted somewhere (*should*, with the meaning that I'd love to do that if I understood even half the discussion here, but it is sadly not the case.) -- Jean-Christophe Helary @brandelune https://mac4translators.blogspot.com https://sr.ht/~brandelune/omegat-as-a-book/
Re: [BUG] Async pdf export broken with native-comp
Hi, Timothy writes: > FWIW I use native-comp (with Doom + my config) and async PDF export > works. Would you mind checking that ~org-latex-export-to-pdf~ is native compiled, using =describe-function= ? I've updated to latest emacs master and I'm still hitting this issue, although the steps to reproduce in my original mail are wrong : + with =emacs -q= async export fails, but for a different reason : I get a =wrong argument stringp, nil= error because ~user-init-file~ is nil inside ~org-export-async-start~. + The issue I described occurs when you use an empty init.el file and start =emacs=. Perhaps you need to make sure that ~org-latex-export-to-pdf~ is native compiled. Regards, -- Sébastien Miquel
Re: org-mode export to (latex) PDF
Maxim Nikulin writes: > Do Unicode TeX engines support such combination of fonts? Yes, they do. My rather long response was due to my impression that you are quite surprised that not everything is supported with the default configuration as you expected. I wanted to highlight that it is even today a rather hard problem to mix different scripts (even if typographic quality does not matter) and that there are quite different expectations of what a sensible default should look like. > 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. Yes, indeed. And I hope you see that these two requirements are not easily satisfied with the same default configuration (and I would say this is a understatement). The LaTeX community has chosen to prefer a minimum typographic quality for their defaults and the majority still concentrates more on latin scripts. And as I said: A good multi-lingual support for Org is a really huge undertaking. Unicode alone solves only a rather minor part of these challenges. > I mean detection if LuaLaTeX or XeLaTeX is usable from Org code. Org should be rather flexible about the configured engines. There are reasons why today all three engine are quite alive and used by different users. I think it would be possible to improve the support for all three engines, make the selection easier for the Org user and go some first steps in better supporting different scripts and languages. But it is not easy and not a matter of a handful lines of code. > Randomly chosen examples: "日本", "多喝水", "📞". The last glyph ("TELEPHONE RECEIVER") is not visible for me. Remember, that Unicode gets expanded quite often and it is not easy for font developers to keep up. I still think that the expectation, that Org and/or LaTeX will support the whole Unicode range out of the box is a little bit too far fetched. -- Until the next mail..., Stefan.