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.
Re: [BUG] Async pdf export broken with native-comp
Timothy writes: > Mark Barton writes: > >> I use native-comp, but have not tried the async export yet. > > FWIW I use native-comp (with Doom + my config) and async PDF export > works. It might be useful for the OP if you could post what commit of Emacs 28 you are running. Native compilation is a moving feast and it could be either the OP is running an older version (and issue has been fixed) or a later version (and issue has been recently introduced). Knowing which commit you are building from might help him identify whether an update might fix the issue. One thing I did notice when I was running native-comp was that the caching strategy was a little hit and miss - it could also be that your version is not running native compiled org. When I was trying native compilation, I found that - native compilation was a bit restrictive - it didn't compile things correctly in some situations because it didn't load some dependencies (i.e. you got errors and warning you don't see with normal *.elc compilation) - The caching was a bit hit and miss - There was no noticeable performance improvement. I think all of these issues will eventually be addressed as things mature. However, for now, I don't see any real benefit in enabling native compilation other than on an academic level. -- Tim Cross
Re: [BUG] Async pdf export broken with native-comp
Mark Barton writes: > I use native-comp, but have not tried the async export yet. FWIW I use native-comp (with Doom + my config) and async PDF export works. -- Timothy
Re: org-mode export to (latex) PDF
> On Jul 15, 2021, at 4:05, Stefan Nobis wrote: > >> 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. The issue I'm pointing at is that we don't need "satisfactorily", we need "good enough". There are a number of fonts that have 30k+ glyphs. That's good enough for a lot of org-mode users. https://en.wikipedia.org/wiki/Unicode_font What we need is 1 or 2 well-documented settings where we specify: 1) the back end 2) the font It can be org proprieties, or extra elisp code, it doesn't matter. But we need to have good enough PDF export out of the box. We're in the 21st century. People expect (I know, free software, etc. but I'm not talking about that) proper font support for PDF, and well-documented workaround solutions. I don't mind going through the org→ODF→PDF route, but it's a waste of time. Still, it works *well enough* so it's actually the only viable option. -- Jean-Christophe Helary @brandelune https://mac4translators.blogspot.com https://sr.ht/~brandelune/omegat-as-a-book/
