After the recent release of KBibTeX 0.9.3.2 as the last release of the 0.9.x branch, it is now time to make a stable release of KBibTeX 0.10.0. Tar-balls are as usual available at KDE’s download mirrors. Some of the changes were documented more than two years ago in a pre-release (0.9.90), but here are the highlights taken from the ChangeLog:
Thank you to everyone who contributed. Happy compiling and packaging!
KBibTeX 0.9.3.2 got released, tar-balls are available at KDE’s download mirrors. This is the last release of the 0.9.x branch. Next is 0.10, where I will prepare release candidate tar-balls in the next few days and hopefully we will see a final release 0.10.0 this Spring.
A number of issues got fixed, including but not limited to:
See the full ChangeLog for all the details.
Some spoilers about what is happening in the ‘master’ branch: I have been working on an exporter to Microsoft Word’s bibliography XML. Writing scientific manuscripts with references in Word is a painful experience, but this exporter allows you to continue to use your favorite BibTeX editor even under dire circumstances.
After some procastination, here comes KBibTeX 0.10 Beta 1 (0.9.90). I had hoped to release it still in 2020, but there is real life and some thing you always want to fix first before making a release. But at some point, one has to make a decision to prepare the release and this point in time has come.
Here is an extract from the ChangeLog, highlighting the changes and fixes since the latest 0.9.x release.
The source code in tar-ball form is available at KDE’s download infrastructure, signed with GnuPG using key 1808CB466328F4380685A3B1A264FD738D861F41.
Now that the release process is underway, I want to progress towards a stable release this spring. As a package maintainer, you can test if package building is working (note the changed ICU and QOAuth dependency) and then provide experimental packages to brave users for testing.
Branch kbibtex/0.10
where this beta release comes from
and all future 0.10.x release will come from, will only release bug
fixes, both towards the stable 0.10 and any potential bugfix releases
(e.g. 0.10.1). Active development happens or will appear in the
master
branch as usual. I will wait for creating a branch
for 0.11 until 0.10 has proven to be sufficient stable, avoiding to port
patches between branches master
, kbibtex/0.10
,
and kbibtex/0.11
.
In a recent blog posting I presented some code on how to transliterate common Unicode characters into ASCII-only representations using a offline-generated lookup table to avoid dependencies on ICU which would normally do this job.
By an anonymous commenter, I got pointed to that Unicode (in Qt) is slightly more complicated than I had considered when writing the code: I missed to handle planes beyond the Basic Multilingual Plane (BMP) and the ‘surrogates’ between code points 0xD800 and 0xDFFF. In a series of recently pushed Git commits I addressed problem of surrogates and fixed some more issues. Some preparatory work has been done to support more planes in the future, but as of now, only the BMP is supported. For details, please have a look at the five commits posted on 2019-10-12.
The release of KBibTeX 0.10 is approaching with the release of KBibTeX 0.10-alpha2 aka 0.9.81.
Improvements and changes since 0.9.2 are less on the user interface, but on the code behind it:
For a more complete list of changes, have a look at the ChangeLog and the source code differences in Git.
As this is an ‘alpha’ release, I suspect there may be some rough edges I missed so far. For example, the build system (CMakeLists.txt files) has been refactored and dependencies updated, so package builders’ old specification files may need an overhaul as well. Translators need to check if all strings are properly translated and still make sense.
If you encounter any issue or bug, please report it at KDE’s bugtracking system; there is already a version tag ‘0.10’.
Many thanks go to contributors such as bug reporters, translators, and everyone else who contributed to KBibTeX!
Source code is available as tar ball, cryptographically signed using GnuPG key 1808CB466328F4380685A3B1A264FD738D861F41.
Finally, after a long waiting period, KBibTeX 0.9.2 got tagged, tar-balled, and released! It is a bug fix release, so virtually no new features since 0.9 got released; dependencies have not changed.
The highlights from the ChangeLog include:
Source code is available at KDE’s download servers: kbibtex-0.9.2.tar.xz and kbibtex-0.9.2.tar.xz.asc (signed with GnuPG key).
If you find bugs, please report them at KDE’s bugtracking system.
I do not plan any further releases of version 0.9.x. Instead, 0.10 is well on the way: as you can see from its ChangeLog, there are plenty of changes already queued up. The ‘master’ branch contains even more changes.
Many thanks to the people who supported this release and make the continuous development of KBibTeX possible!
KBibTeX is a bibliography editor (BibTeX and somewhat BibLaTex) used in conjunction with LaTeX and friends. Based on this code base, a SailfishOS client called ‘BibSearch’ exists which allows to search for bibliographic data in various online sources (IEEE Xplore, Google Scholar, ACM Digital Library, …). BibSearch’s code makes use of KBibTeX’s C++ code, has its user interface implemented in SailfishOS’s Silica QML, and provides just two C++ files on its own to glue together everything.
It has long been my goal to provide a QML or Kirigami-based client of KBibTeX of similar functionality, either to be used as Plasma widget or for Plasma Mobile (thus equivalent to the SailfishOS implementation). Finally I have been able to put together an initial implementation using Kirigami2. There are several rough edges and bugs, and much of the intended functionality is missing, but at least one can search for bibliographic data. If you are familiar with Kirigami, it should be a low-hanging fruit to fix the obvious issues, especially given that there is already a Silica-based client as reference. Code contributions to branch feature/kirigami are welcome!
So far, most of my blog postings that appeared on Planet KDE were release announcements for KBibTeX. Still, I had always planned to write more about what happens on the development side of KBibTeX. Well, here comes my first try to shed light on KBibTeX’s internal working …
Active development of KBibTeX happens in its master
branch. There are other branches created from time to time, mostly
for bug fixing, i. e. allowing bug reporters to compile and test a bug
fix before before the change is merged into master
or a
release branch. Speaking of release branches, those get forked from
master
every one to three years. At the time of writing,
the most
recent release branch is kbibtex/0.9
. Actual releases,
including alpha or beta releases, are tagged on those
release branches.
KBibTeX is developed on Linux; personally I use the
master
branch on Gentoo
Linux and Arch Linux. KBibTeX
compiles and runs on Windows with the help of Craft
(master
better than kbibtex/0.9
). It is on my
mental TODO list to configure a free Windows-based continuous
integration service to build binary packages and installers for Windows;
suggestions and support are welcome. Craft supports macOS, too, to some
extend as well, so I gave KBibTeX a shot on this operating system (I
happen to have access to an old Mac from time to time). Running Craft
and installing packages caused some trouble, as macOS is the least
tested platform for Craft. Also, it seems to be more difficult to find
documentation on how to solve compilation or linking problems on macOS
than it is for Windows (let alone Linux). However, with the help of the
residents in #kde-craft
and related IRC channels, I was eventually able to start compiling
KBibTeX on macOS (big thanks!).
The main issue that came up when crafting KBibTeX on macOS was the problem of linking against ICU (International Components for Unicode). This library is shipped on macOS as it is used in many other projects, but seemingly even if you install Xcode, you don’t get any headers or other development files. Installing a different ICU version via Craft doesn’t seem to work either. However, I am no macOS expert, so I may have gotten the details wrong …
Discussing in Craft’s IRC channel how to get KBibTeX installed on macOS despite its dependency on ICU, I got asked why KBibTeX needs to use ICU in the first place, given that Qt ships QTextCodec which covers most text encoding needs. My particular need is to transliterate a given Unicode text like ‘äåツ’ into a 7-bit ASCII representation. This is used among others to rewrite identifiers for BibTeX entries from whatever the user wrote or an imported BibTeX file contained to an as close as possible 7-bit ASCII representation (which is usually the lowest common denominator supported on all systems) in order to reduce issues if the file is fed into an ancient bibtex or shared with people using a different encoding or keyboard layout.
Such a transliteration is also useful in other scenarios such as if
filenames are supposed to be based on a person’s name but still must be
transcribed into ASCII to be accessible on any filesystem and for any
user irrespective of keyboard layout. For example, if a filename needs
to have some resemblance the Scandinavian name ‘Ångström’, the name’s
transliteration could be ‘Angstrom’, thus a file could be named
Angstrom.txt
.
So, if ICU is not available, what are the alternatives? Before I adopted ICU for the transliteration task, I had used iconv. Now, my first plan to avoid hard-depending on ICU was to test for both ICU and iconv during the configuration phase (i. e. when cmake runs) and use ICU if available and fall back to iconv if no ICU was available. Depending on the chosen alternative, paths and defines (to enable or disable specific code via #ifdefs) were set. See commit 2726f14ee9afd525c4b4998c2497ca34d30d4d9f for the implementation.
However, using iconv has some disadvantages which motivated my original move to ICU:
Is there a third option? Actually, yes. Qt’s Unicode code supports only the first 216 symbols anyway, so it is technically feasible to maintain a mapping from Unicode character (essentially a number between 0 and 65535) to a short ASCII string like AE for ‘Æ’ (0x00C6). This mapping can be built offline with the help of a small program that does link against ICU, queries this library for a transliteration for every Unicode code point from 0 to 65535, and prints out a C/C++ source code fragment containing the mapping (almost like in the good old days with X PixMaps). This source code fragment can be included into KBibTeX to enable transliteration without requiring/depending on either ICU or iconv on the machines where KBibTeX is compiled or run. Disadvantages include the need to drag along this mapping as well as to updated it from time to time in order to keep up with updates in ICU’s own transliteration mappings. See commit 82e15e3e2856317bde0471836143e6971ef260a9 where the mapping got introduced as the third option.
The solution I eventually settled with is to still test for ICU
during the configuration phase and make use of it in KBibTeX as I did
before. However, in case no ICU is available, the offline-generated
mapping will be used to offer essentially the same functionality.
Switching between both alternatives is a compile-time thing, both code
paths are separated by #ifdef
s.
Support for iconv has been dropped as it became the least complete solution (see commit 47485312293de32595146637c96784f83f01111e).
Now, how does this generated mapping look like? In order to minimize
the data structure’s size I came up with the following approach: First,
there is a string called const char *unidecode_text
that contains any occurring plain ASCII representation once, for example
only one single a that can be used for ‘a’, ‘ä’, ‘å’, etc. This string
is about 28800 characters long for 65536 Unicode code points where a
code point’s ASCII representation may be several characters long. So,
quite efficient.
Second, there is an array const unsigned int unidecode_pos[]
that holds a number for every of the 65536 Unicode code points. Each
number contains both a position and a length telling which substring to
extract from unidecode_text to get the ASCII representation. As the
observed ASCII representations’ lengths never exceed 31, the array’s
unsigned ints contain the representations’ lengths in their lower (least
significant) five bits, the remaining more significant bits contain the
positions. For example, to get the ASCII representation for ‘Ä’, use the
following approach:
const char16_t unicode = 0x00C4; ///< 'A' with two dots above (diaeresis)
const int pos = unidecode_pos[unicode] >> 5;
const int len = unidecode_pos[unicode] & 31;
const char *ascii = strndup(unidecode_text + pos, len);
If you want to create a QString
object, use this instead
of the last line above:
const QString ascii = QString::fromLatin1(unidecode_text + pos, len);
If you would go through this code step-by-step with a debugger, you
would see that unidecode_pos[unicode]
has value 876481
(this value may change if the generated source code changes). Thus, pos
becomes 27390 and len becomes 1. Indeed and not surprisingly, in
unidecode_text at this position is the character A. BTW, value 876481 is
not just used for ‘Ä’, but also for ‘À’ or ‘Â’, for example.
Above solution can be easily adjusted to work with plain C99 or modern C++. It is in no way specific to Qt or KDE, so it should be possible to use it as a potential solution to musl (a libc implementation) to implement a //TRANSLIT feature in their iconv implementation (I have not checked their code if that is possible at all).
Finally, KBibTeX 0.9 got released. Virtually nothing has changed since the release of beta 2 in May as no specific bugs have been reported. Thus ChangeLog is still the same and the details on the changes since 0.8.2 as shown on the release announcement for 0.9-beta2.
Grab the sources at KDE’s download mirrors.
I am glad to announce the availability of KBibTeX 0.9 Beta 2 (0.8.91) for download. Whereas Beta 1 had some issues and was never formally announced, Beta 2 is quite stable and ready to use for everyone able to compile and install from a tar-ball and willing to test code.
Changes so far and compared to 0.8.2 are as follows (taken from the ChangeLog):
The source code in tar-ball form is available at KDE’s download infrastructure: https://download.kde.org/unstable/KBibTeX/kbibtex-0.8.91.tar.xz Signed with GnuPG: https://download.kde.org/unstable/KBibTeX/kbibtex-0.8.91.tar.xz.asc (key: 1808CB466328F4380685A3B1A264FD738D861F41)
Unless there are severe issues, I plan to make a final release of 0.9 in early summer.
The current master
code contains a number of changes due for 0.10, such as refactored
preferences/settings system and better integration to GitLab’s CI
system both to run automated tests as well as to run a Coverity Scan,
among others. If you want to test some bleeding edge, pull the code from
KDE’s Git
repository.
A common problem with bug reports received for KBibTeX is that the
issue may already be fixed in the latest master
in Git or
that I can provide a fix which gets submitted to Git but then needs to
be tested by the original bug reporter to verify that the issue has been
indeed fixed for good.
For many distributions, no ‘Git builds’ are available (or the bug reporter does not know if they exist or how to get them installed) or the bug reporter does not know how to fetch the source code, compile it, and run KBibTeX, despite the (somewhat too technical) documentation.
Therefore, I wrote a Bash script called run-kbibtex.sh
which performs all the necessary (well, most) steps to get from zero to
a running KBibTeX. The nicest thing is that all files (cloned Git repo,
compiled and installed KBibTeX) are placed inside /tmp
which means no root or sudo
are required, nor are any
permanent modifications made to the user’s system.
There is a README.txt
file explaining the script in greater detail.
The only requirement is that the user installs the usual KDE-related
development tools and libraries. If a tool or library is missing, the
script will abort, but the error message (most likely some output from
cmake
) can be searched for in order to learn which package
to install. Once this is done, simply restart
run-kbibtex.sh
until all steps succeed.
I have tested the script with several Linux distributions and gave earlier versions to bug reporters for testing, so I am almost sure that it will work as promised. Please send suggestions or bug reports via email to me.
As promised, here comes the one intermediate pre-release between KBibTeX 0.7.90 (0.8-beta1) and the final release of 0.8: KBibTeX 0.7.95 aka 0.8-rc1. The most important changes between Beta1 and RC1 are the following:
The release is available on KDE’s mirror infrastructure:
9a13ea22a82c022f76fecea927b56cb7897d5baf4dbf515f08760bef8b168515
)1808CB466328F4380685A3B1A264FD738D861F41
(available here
and here)Now is your last chance to find show-stopping bugs!
P.S. I plan to write soon a blog posting on the implemented and planned changes for KBibTeX 0.9 (hopefully still to be released in 2018).
After almost exactly two years of being work-in-progress, the first stable release of KBibTeX for KDE Frameworks 5 has been published! You can grab the sources at your local KDE mirror. Some distributions like ArchLinux already ship binary packages.
After one beta and one release candidate, now comes the final release.
You may wonder why this release gets version number 0.8.1 but not 0.8 as expected. This is simply due to the fact that I noticed a bug in CMakeLists.txt when computing version numbers which did not work if the version number just had two fields, i. e. no ‘patch’ version. As the code and the tag of 0.8 was already pushed, I had no alternative than to fix the problem and increase the version number. Otherwise, the ChangeLog is virtually unchanged compared to the last pre-release.
To check the tar-ball, please use the detached, ascii-armored GnuPG signature generate with my GnuPG key 8D861F41. The tar-ball’s checksums are as follows:
Algo | Checksum |
---|---|
SHA1 | 9de2888e49cc62b6d4906235ac5456a640177cbd |
SHA256 | 6511a912925c628b7d175b0ef98ba98b1b8eb61e457d621ea0963d29b1fd21d2 |
Finally, the release of KBibTeX 0.8 is on its track again. I tagged and tar-balled
the code of the current Git
branch kbibtex/0.8
as KBibTeX 0.7.90
(a. k. a. 0.8-beta1) and asked the KDE sysadmins to put
it on KDE’s content distribution network.
Only afterwards I noticed that I totally had forgotten to update the ChangeLog which was still stuck on the ancient release of 0.6.1. Properly updating the changelog records will be my next step. In case I didn’t mention it before, the biggest change from 0.7 to 0.8 is the migration from KDE4 to KDE Frameworks 5. User interface and functionality has stayed surprisingly stable, though.
For you, my fellow KBibTeX users, you may fetch
the tar ball kbibtex-0.7.90.tar.xz
and test if
everything is working for you. This request is especially relevant if
you are a translator or a package maintainer or at least know a little
bit of either to see if translations and/or package building works on
your setup. If you find any issues, please report them at KDE’s Bugtracking System (don’t forget
to set the version in your report to 0.8). There are known bugs in the
code, some of which I fixed in the master
branch (to become
0.9) already but did not integrate into 0.8 due to the feature
freeze.
This release contains code contributions from, among others, Antonio Rojas, Frederik Schwarzer, Joao Carreira and Pino Toscano. Thank you very much!
My preliminary and optimistic time plan predicts a stable, final release of KBibTeX 0.8 at the end of May (this year). There’ll may be some more pre-releases in between in case relevant issues were found and fixed.
Looking forward to your feedback!
After a beta version in September and a release candidate in October, there is finally a release of KBibTeX 0.7. A tag has been set and tar balls have been published.
The only changes compared to the release candidate are attempts to fix online search issues with Google Scholar and IEEE Xplore.
Key | Value |
---|---|
Filename | kbibtex-0.7.tar.xz |
SHA256 | 5d3acdd7cd6da9cb8db23e46cd02b8a6648e516330b169d09a6b6ffe226f9a96 |
Public GnuPG key | 1808CB46 6328F438 0685A3B1 A264FD73 8D861F41 |