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:
>>
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
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
(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
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))
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
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
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
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
>
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
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
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
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
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
> 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
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
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
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
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
> 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
20 matches
Mail list logo
