Let's assume I have got correct .RIS and/or .bib files imported into Mendeley.
When I create the Mendeley Bibliography in a Office Word file articles with many authors are not written correctly by Mendeley with Geophysical Research Letters style.
E.g. see the following pic (note article chosen randomly):
The article above has 13 authors in total but Mendeley only displays 7 of them with also ... as gap between the 6th and 13th author.
I need all authors shown in my bibliography as per Geophysical Research Letters' style.
How can I solve this?
Any help would be really appreciated.
Thanks
The answer to this has multiple parts:
Note that the AGU, which publishes GRL, has recently changed its citation format to APA style as described here: https://eos.org/editors-vox/new-style-for-agu-journals-and-books What you have pasted above is an APA-style citation.
using et al. for 8 or more authors is correct in the new style
However, the elipsis between the 6th and the last author is not supposed to be there, a deviation from APA rules by the AGU style. I have just fixed this in the upstream repository from which Mendeley draws its styles and it should be available for updating within 48hs in Mendeley. The style that actually updates, btw., is American Geophysical Union, all their journals (such as GRL) just point to that style
If you do want to edit et al settings in a CSL style by yourself for used in Mendeley, the easiest way is probably Mendeley's CSL Editor. There, you would click on "Bibliography" on the left and adjust the et al settings. There are three of relevance:
et-al-min which determines the number of authors at which et al kicks in. E.g., it's set to 8 for AGU which means "start using et al for 8 or more authors".
et-al-use-first which determines how many authors are listed before et al. (currently 6 for AGU)
et-al-use-last which determines whether elipsis are used as described above. This can only be true or false.
I was having the same problem and besides changing the Bibliography section, I changed the Global Formatting section and it worked well
Related
I got two different "versions" of Arabic letters on Wikipedia. The first example seems to be 3 sub-components in one:
"ـمـ".split('').map(x => x.codePointAt(0).toString(16))
[ '640', '645', '640' ]
Finding this "m medial" letter on this page gives me this:
ﻤ
fee4
The code points 640 and 645 are the "Arabic tatwheel" ـ and "Arabic letter meem" م. What the heck? How does this work? I don't see anywhere in the information so far on Unicode Arabic how these glyphs are "composed". Why is it composed from these parts? Is there a pattern for the structure of all glyphs? (All the glyphs on the first Wikipedia page are similar, but the second they are one code point). Where do I find information on how to parse out the characters effectively in Arabic (or any other language for that matter)?
Arabic is a script with cursive joining; the shape of the letters changes depending on whether they occur initially, medially, or finally within a word. Sometimes you may want to display these contextual forms in isolation, for example to simply show what they look like.
The recommended way to go about this is by using special join-causing characters for the letters to connect to. One of these is the tatweel (also called kashida), which is essentially a short line segment with “glue” at each end. So if you surround the letter م with a tatweel character on both sides, the text renderer automatically selects its medial form as if it occured in the middle of a word (ـمـ). The underlying character code of the م doesn’t change, only its visible glyph.
However, for historical reasons Unicode also contains a large set of so-called presentation forms for Arabic. These represent those same contextual letter shapes, but as separate character codes that do not change depending on their surroundings; putting the “isolated” presentation form of م between two tatweels does not affect its appearance, for instance: ـﻡـ
It is not recommended to use these presentation forms for actually writing Arabic. They exist solely for compatibility with old legacy encodings and aren’t needed for correctly typesetting Arabic text. Wikipedia just used them for demonstration purposes and to show off that they exist, I presume. If you encounter presentation forms, you can usually apply Unicode normalisation (NFKD or NFKC) to the string to get the underlying base letters. See the Unicode FAQ on presentation forms for more information.
I am turning to use Sublime3 instead of Notepad++. I have some concern when working with Perl/PHP or any kind of languages that use dollar sign for declare variable.
Here is an example, in Notepad ++:
As can be seen, "HELO $name" was displayed with different colors.
By that way, we can easily recognize there is a variable in the string.
In Sublime 3 , it looked like this:
So you can see there are no different between text and variable. It would caused confusion in some case.
May I know is there are any solution for this ?
Thank you and best regards.
Alex
This is self-promoting, but it will actually solve the problem
You may want to check out my Neon Color Scheme, available via Package Control. Its goal is to make as many languages as possible look as good as possible, and has hundreds of selectors that are specific for many different syntaxes, including Perl and PHP. Specifically, both languages support highlighting for string interpolation. Here is your code using Sublime's Perl syntax from dev build 3118, which should be very similar to the latest public build, which you should be using if you're not registered yet:
And here is the equivalent code in PHP:
Please note that these images were taken using a work-in-progress version of Neon, which I'm planning on releasing in the next day or so. The current version should look the same, as I don't think I've edited any of these scopes, but if not just let me know and I'll point you to the dev version.
I am using Node.js, on SUSE. When system language is Japanese (my locale is ja_JP.UTF-8), node shows
Japnese characters as square boxes (For links to Japanese website)
Even tried i18n localization, with properties files for Japenese language.
Node displays all Japanese fonts as boxes. Window.Navigator.language does show "ja".
And things works great when language is English or French.
I tried different fonts but observed the similar issue.
re-searching for multilingual IDE (integrated development environment) i am wanting to build, and it would seem Japanese has a few competing formats, which are not utf-8, the kanji / ganji (spelling) has more letters / symbols than other written languages. and a few sites noted competing formats in japan other that utf notations.
http://icu-project.org/ gets data from http://cldr.unicode.org/ from what i understand a lot of software unix / linux / microsoft other big companies use the data. looking at chrome and nodejs, i saw notations of Japanese in a license file. but beyond that i did not find much more info. the cldr site seems iffy on amount of data for japan compared to other languages when skim reading over handful of files to see what data was in the cldr core files.
with above said, make sure you are setting the html header utf-8 correctly, see if a lang tag works
< span lang="jp">some text here</span>
i do not know were i read it, it was not kanjo (spelling) but i want to say ganji? (spelling) or rather the "vertical" reading not left to right, or right to left, but vertical reading (from top -> down). and to get things to display correctly it was being placed into "square boxes".
I am using the Hit Highlighting feature in Azure Search and noticed a discrepancy in the way it behaves from the documentation. In the documentation it says that when you use hit highlighting it will return a snippet of the field with the highlight, but it always returns the entire field (with proper highlighting).
Is there a way to have Azure Search instead return just a snippet (say of about 200 characters) that includes the highlight?
Currently, the answer is no, you cannot. The field breaks according to (English) sentence rules, ie. it breaks on ".", "!", "?".
Also see this question for an example on breaking and some more info relating to the delimiters.
Depending on the nature of the field you might be able to add one of the above delimiters to 'emulate' what you want to accomplish (as suggested by Nate Ko).
I want to suggest something else on top of what Nate spoke to. When you look at the document response, also take a look at the Highlights part of the results (as opposed to the Document). For example, you might be currently getting the field results by retrieving something like this:
Results[i].Document.DESCRIPTION
If there is a highlight found for that field, the snipped will be found here:
Results[i].Highlights.DESCRIPTION
What I like to do is to first check if there is a valid Highlight and if so display it. If not, I show the actual field content.
Liam
We recently introduced a change that improves the highlighter performance on large fields and NLP experience. One side effect of the change was that the new highlighter generates snippets based on sentences, breaking the text field on '.' (period).
One way to workaround the issue is to put '.'s in the field. We are working to enforce the snippet size and let you know when it is available.
My thesis is written in b5j documentclass style.
\documentclass[b5j,twoside,12pt]{report}
I have a paper that is appended at the end. However this is written in b5paper style as an article.
\documentclass[12pt,b5paper,twoside]{article}
How do I get the paper to follow the japanese style? Havent found any b5paperj options in the geometry package.. :-/
It is possible to build the paper that must be appended separately and input it in your document using pdfpages. This way you don't have to control both styles and the package provides enough flexibility to make it look like you want to.