• When registering fonts, the font weight is determined by the style name. Previously, without this, some font variants were discarded as duplicates.
• The software one-position embolding of the font in the absence of a bold version is replaced with multi-step change of the font weight. Also implemented compensation for under/over-width characters when setting fake/synthetic font weight. Document property 'PROP_FONT_BASE_WEIGHT' (font.face.base.weight) replaces 'PROP_FONT_WEIGHT_EMBOLDEN' (font.face.weight.embolden). Document command 'DCMD_SET_BASE_FONT_WEIGHT' replaces 'DCMD_TOGGLE_BOLD'.
• Desktop/Qt5: frontend updated to be able to change font weight in settings.
• Android: frontend updated to be able to change font weight in settings.

Screenshots: Font 'Noto Serif' full set of weights:

Font 'Coming Soon' (only Regular):

Book view with 'Coming Soon' regular:

Book view with 'Coming Soon' ExtraBold (fake/synthetic):

Updated (20200330): added screenshots of synthetic weight for some arabic/hebrew text: NotoSans + NotoSans Arabic UI Regular: NotoSans + NotoSans Arabic UI Black (real): NotoSans + NotoSans Arabic UI Black (both synth): NotoSans Arabic UI Black (real) in Chromium:

I recently discovered collision in the license for the CoolReader source code, which seems to violate the project's license. Examining the README.md file, we see that the license is "GPLv2 only". But in most source files, the comment header says:

                CoolReader Engine

        (c) Vadim Lopatin, 2000-2009

        This source code is distributed under the terms of
        GNU General Public License.
        See LICENSE file for details.

The LICENSE file was missing and only appeared in PR #205. The LICENSE file contains the text of the GPLv2 license. According to section 9 of GPLv2: "If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation." But the README.md file clearly says "All source codes (except thirdparty directory) are provided under the terms of GNU GPL license, version 2", i.e. "GPLv2 only". The essence of the collision: according by several source files - they can be used under the terms of GPLv1, GPLv2, GPLv3 and, in the future, newer, but the README file limits us to version 2, and in some files there is no information about the license used at all. For CoolReader, this matters because the Android framework libraries are used (which theoretically can be considered as system libraries, which is allowed https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException) and until recently used the Android JetPack libraries (or rather AndroidX), distributed under the terms of the Apache-2.0 license, which are not GPLv2 compliant but GPLv3 compliant, and if you focus on the README file, then it turns out they cannot be used. The code using the AndroidX library was added in PR #177 and removed in PR #336, but using this approach is unproductive and, in my opinion, unacceptable, instead of implementing some functionality in the most convenient way, we have to look for some workarounds, just not to use the code under the Apache 2.0 license. Reminds me of a fighting with windmills. For the KOReader project, this also matters, since the KOReader license (AGPLv3) is incompatible with the license of the used crengine library (a fork of CoolReader, presumably GPLv2 only), and according to the explanation of a single combined program https://www.gnu.org/licenses/gpl-faq.html#GPLPlugins licenses must be compatible.

I requested advice from the FSF by sending an email to [email protected], below is the response without any corrections or cuts:

from: Yoni Rabkin via RT [email protected] Date: 19 июн. 2022 г., 16:47 Subject: [gnu.org #1845021] Re: license question about CoolReader program

Hello and thank you for writing in.

Hello! Please give an explanation about the compatibility of licenses.

There is a CoolReader program, its repository is located at  https://github.com/buggins/coolreader/ , it is present in the Google Play app store, F-Droid directory, in some Linux distributions, for example, Fedora, Gentoo Linux.

At the moment, the version for Android is quite popular, but, unfortunately, it is not currently being developed.

According to the README.md file, the GPLv2 license is used. In most source files, the comment header says the following:

CoolReader Engine

(c) Vadim Lopatin, 2000-2009

This source code is distributed under the terms of GNU General Public License. See LICENSE file for details.

The LICENSE file contains the text of the GPLv2 license.

As I understood from the clarifications on the gnu.org website, without specifying the license version, any version of your choice is implied, i.e.  and version 2 and version 3. In addition, the license is specified differently in the two header files:

    This program is free software; you can redistribute it and/or modify     it under the terms of the GNU General Public License as published by     the Free Software Foundation; either version 2 of the License, or     (at your option) any later version.

And some files say nothing at all about the license used.

Which project file has higher priority when specifying a license, README or source files and, accordingly, what kind of license does this project have "GPLv2 only" or "GPLv2 or later"? (1)

Ultimately, only the copyright holder can answer as to what they meant when they licensed the work in this way. There may be some reasoning behind it; we can't say.

The Android version uses the Android framework libraries under the Apache 2.0 license, which is not compatible with GPLv2, but is compatible with GPLv3, GPLv3, in turn, is not compatible with GPLv2. However, I believe that these libraries are system libraries and their use in a program under the GPLv2 license is allowed:  https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException

I haven't examined the Android libraries in question and cannot say if they would be considered system libraries. One criteria you can examine is if the libraries in question are normally distributed with the Android system and are used to enable use of the system.

It is also possible that the CoolReader program has had incompatible licensing all this time.

One way of working around this particular issue would be for the copyright holder to add an exception for the Apache 2.0 licensed materials: http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs

Currently, Android application development usually involves the use of Android JetPack libraries under the Apache 2.0 license (Google developer). Mainly used by AndroidX https://developer.android.com/jetpack/androidx

At the same time, the AndroidX library is not a system library, therefore, it cannot be used in this project.

Is it so? (2)

This may be the case, yes. But as above, it is possible that through carelessness the copyright holders of the work have created a bit of a licensing mess.

Are there any options for using the CoolReader sources under the GPLv3 license? (3)

At least partially, yes, but there may be parts which would require work. Those parts that have clear license headers can be upgraded. Those parts which do not specify a GPL version can be upgraded as well.

Parts that have no licensing information require clarification; we don't know if they are under a free software license of any kind.

If they are not, then the question arises of changing the license from GPLv2 to GPLv3.

In this regard, I contacted the main developer of CoolReader Vadim Lopatin < [email protected]> with a request to upgrade the license to GPLv3, to which he asked if agreement with all contributors was required. And it seems, according to the license, it is required. The program is many years old, many developers have ceased their participation, I do not have their contacts, the original developer has also ceased development and is unlikely to be interested in finding former contributors. I am more than sure that some contributors are simply not to be found.

The main developer can at least give you authorization to upgrade those parts of the work for which they are the copyright holder. This can be as simple as them adding proper copyright notices and GPLv3 license headers to the files for which they hold the rights, and giving you a copy.

If there is code in the project with unclear provenance, or for which you are unsure of the license, then you cannot distribute that code with any confidence. I would recommend trying to clear up the situation for that code.

Is it possible to limit the number of developers with whom you need to agree on a license change based on the clarification of a small contribution? (4)

See https://www.gnu.org/licenses/gpl-faq.ru.html#WhatIfWorkIsShort

That is a matter of legal advice, and we cannot provide that.

If in doubt, you would need to remove that code and re-implement it independently.

How should the procedure for replacing the license of a non-commercial open source application from GPLv2 to GPLv3 go? (5)

In what form is an agreement from developers required to change a license, in electronic form, in paper form, what type of signature is required? (6)

If, hypothetically, the consent of all contributors is obtained, is it required to publish any supporting documents before changing the license? Is it enough to point in the README that the contributors have agreed to change the license? (7)

These developers supposedly sent in patches under GPLv2, and no paperwork signatures were required back then; so none would be needed now. All that is needed is for them to send in a patch of the code for which they hold the copyright with GPLv3 headers instead of GPLv2. Or with GPLv2 headers with a clear "or later" statement.

Please note that it is not beyond possibility that through carelessness and negligence in licensing the original developers have doomed the project. Hopefully, you can at least salvage some of the software.

I hope this is of help.

-- I am not a lawyer, the above is not legal advice

   Regards, Yoni Rabkin

from: Yoni Rabkin via RT [email protected] Date: Mon, 20 Jun 2022 09:31:31 -0400 Subject: [gnu.org #1845021] Re: license question about CoolReader program

To do this, I plan to create a discussion (issue) in the project repository on github, can I post your answer?

Please feel free to post my answer publicly. I only ask that you do so in full and verbatim so that the entire context of my responses is clear.

It's also not very clear to me what to do with files whose author is the main developer, who indicated the GPL license without a version in the file header

I understand that you have some contact with the main developer. I would therefore recommend clarifying with the main developer/copyright holder that wherever they had placed a license header without a version, that it should be replaced with a standard GPL license header which includes the version and with the "or later" clause (which is standard practice.)

You can point out to them that as per section 9 of GPLv2: "If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation."

But of course doing this in coordination with the copyright holder is always better than doing it independently.

and which were extended by contributors. Basically, they did not change the file headers in any way, i.e. they did not indicate > their copyright and the author of the edits can only be found in the git history. What should they add to the header of the file?

If they contributed to a file which was clearly marked as under the GPL (regardless of version) then they could only have license their contribution under the GPL or a GPL-compatible license. Anything else would risk being if violation of the GPL if they were to distribute the GPL'd work with GPL-incompatible modifications. So unless they intended to violate the GPL, their contributions would have to have been under compatible terms.

However, if nobody recorded their the license or copyright notices then you will have to start reconstructing the licensing of the project in retrospect.

Each contributor should have a copyright notice. These copyright notices are ideally placed at the top of the file modified. However, they can also be concentrated in a single file, such as an "AUTHORS" file. Each of the copyright notices would take the form of:

"Copyright (C) 2017, 2019 Man McGent [email protected]"

An email is optional, but helpful for reasons which should now be obvious to you.

If they contributed under the GPL, then no change needs to be made for the license header; it will still be the standard GPL license header as shown at the bottom of the GPL license text in the section "How to Apply These Terms to Your New Programs"

If they contributed under a GPL-compatible license, then you would add that license information:

"Copyright (C) 2017, 2019 Man McGent under the Expat license, see LICENSE.EXPAT"

The goal being that each file will contain all of the information needed so that people will be able to know who is the copyright holder of that material, and under which license they can enjoy the work.

P.S. I am also the maintainer of software which belongs to the GNU project. When I inherited the maintainership of the project, the licensing situation was similar to the one you describe above (which is to say, bad). It took me over a year to contact people, clarify the licensing, and re-write "orphan" parts, but I did it in the end and the project is now alive and well. I say this in order to strengthen your resolve, and to say that I understand the magnitude of the problem.

-- I am not a lawyer, the above is not legal advice

Regards, Yoni Rabkin

If I understand correctly, in order to eliminate this collision and ambiguities about the license used, we need to perform one of the options: 1. check with the main developer what exactly was meant by the phrases «This source code is distributed under the terms of GNU General Public License. See LICENSE file for details» и «All source codes (except thirdparty directory) are provided under the terms of GNU GPL license, version 2», whether inadvertently limited the GPL version to v2 only or is this explicit restriction; 1.1. If the author meant GPLv2 or later, then it is necessary to agree with all copyright holders, i.e. with all co-authors, whether they agree with such an interpretation, i.e. with the fact that their work will be used under the terms of the GPLv3 or later license, since they could be misleading due to a non-standard indication of the license used; 1.2. If the author meant GPLv2 only, then find out from the author whether it is against changing the wording to GPLv2 or later, and also coordinate this change with all copyright holders, since they could be misled due to a non-standard indication of the license used; 1.3. In all cases, if the response from the copyright holder/co-author is not received or it is negative, it is necessary to delete the corresponding code and rewrite it from scratch. 2. Update license statement to GPLv3 or later. This is the cleanest use case for Apache 2.0 licensed code/libraries. It is necessary to agree with all copyright holders/co-authors, if the response from the copyright holder/co-author is not received or it is negative, it is necessary to delete the corresponding code and rewrite it from scratch. 3. (useless option) copyright holders add exception for licensed Apache 2.0 material: http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs. It is also necessary to agree with all copyright holders/co-authors, if the response from the copyright holder/co-author is not received or it is negative, it is necessary to delete the corresponding code and rewrite it from scratch. In terms of the amount of work, all these options are equal, so the 3rd option is of little use, since it gives very little benefit.

In addition, we need to do the following: • Identify all copyright holders/co-authors from the git history and patch authors in the previous project repository https://sourceforge.net/projects/crengine/ and create a file with the list of authors; • Since the FSF recommends placing copyright information in the header of source files, reconstruct this licensing information in retrospect.

I understand that in this case the license is violated absolutely symbolically, not by malicious intent, but as a result of a careless indication of the project license and the violation is rather minor, I believe that the spirit of the license is not violated, it's just a collision. But after discovering this situation, realizing the illegitimacy of the license, the senselessness of working on the project is felt.

If I am mistaken and CoolReader sources can be used under the terms of the GPLv3 license without taking any additional steps, please clarify it.

The opinion of the community, including KOReader, is interesting.

I suggest that all CoolReader co-authors present on github choose an option by leaving a comment: 1. Set project license to clearly GPLv2 or later; 2. Update project license to GPLv3 or later; 3. Add an exception for the Apache 2.0 licensed materials; 4. Do nothing, leave everything as it is. Then try to get opinions from patch authors not present on github, for example, patches posted on sourceforge https://sourceforge.net/p/crengine/patches/search/?q=status%3Awont-fix+or+status%3Aclosed-fixed+or+status%3Aclosed, find out if there were other patch sources (seems impossible), choose the most popular answer. Take further actions based on the results of the vote. Pinging @buggins, @pkb, @avnik, @S-trace, @ourairquality, @EXL, @Frenzie, @poire-z, @pazos.

Voting results: https://github.com/buggins/coolreader/issues/338#issuecomment-1164266957

This PR should close #91. It includes a lot of enhancements in css processing, thanks to koreader devs and especially to poire-z for work on crengine.

It wasn't that easy to merge, in case of conflicts I mostly accepted their side. Except for kerning mode setting, We handle it differently - we use a combination of new setting "Text shaping mode" and the old Kerning enable/disable.

They have added qimagescale from QT, I moved it to thirdpatrty folder. I also added nanosvg library to the thirdparty folder, harfbuzz I updated to 2.6.4 version.

Note: this change is not yet ready for Android, @virxkane will create a separate request for it.

The source included commented out distinct list circle and disc characters which this PR enables. It had been using the same characters for both, and a different character. Could this be revisited now so that there are distinct circle and disc list labels available? Was there are lack of support in the fonts, or was it a presentation decision?

Coolreader updates on F-droid are blocked caused by the recent inclusion of Google services. If I understand correctly they were added to support GDrive sync.

I would like to solve this but I'm not sure if upstream is wishing to spend time on reviewing this. Ideally it would be a couple of folders under android/app/src. Lets call them gplay and fdroid. Within each folder a new class with the same package name and same class name.

That class would be the one that implements methods that rely on GMS within the program. This for the gplay flavor. The Fdroid flavor would include empty methods. Both classes should contain a boolean method called something like isSupported which returns true on the former and false on the later.

The changes needed on the common code would be checking that method response and invoke the specific method needed for a functionality. Something like:

if (gms.isSupported()) {
    gms.doSomething(params)
}

And include gms as a depency only on gplayimplementation

The other alternative would be to fork the project and remove GMS in the fork. That would be easier to implement but harder to keep updated. Pinging @virxkane

• Fixed fb2 coverpage drawing in scroll mode (continuous) with enhanced render.
• Android: use fast (not precise) mode for functions LVDocView::getBookmark() only for page turn & text scroll.
• Optimized calculation of average animation duration.
• Android: fixed scrolling of text around start and end of a book in scrolling mode.
• Improved methods for selecting next/previous sentence when using "***" paragraph separators. In fact, this is a continuation of PR #144, i.e. restoration of old functionality.
• Legacy rendering mode: display block elements that are inside inline elements as block elements.
• Trying to update the structure of a database that has been modified by some kind of uncoordinated fork of the program.
• Forced update the DOM level in database from previous newest to latest newest.

Updates from KOReader:

• New HTML parser, libRu and FB2 tweaks https://github.com/koreader/crengine/pull/370

This is adequate to get the text selection returning the img alt text, and that works with the Read-Aloud feature where it can be very useful.

Seems a bit of a hack, adding a child text element to an img element, but when you consider that the ::before and ::after pseudo elements can be used on the img element and are already added as child elements, and that these are to be emitted around the alt text, this approach is much simpler than having all the users include special cases to emit the alt text out of order with the pseudo elements (I tried that first and it was a big change that I never completed!)

This PR plays well with a WIP patch to get the pseudo elements emitted in text selection and thus for Read-Aloud.

If people have other suggestions then help would be appreciated?

With the Qt version of the app on a high DPI display the text in the book's canvas is blurry, not rendered properly. App version: 3.2.57-1 O/S: Manjaro Linux Global scaling factor: 2

How it looks compared to unscaled (bottom):

• Fix index out of range in lString32::pos(lChar32) introduced in cc51fc6ff1336bc87ebaf146ee04b18207331d4a
• Do not render the Unicode character 'WORD JOINER' (U + 2060) as a replacement character if the font does not have a corresponding glyph for it in SHAPING_MODE_HARFBUZZ_LIGHT and SHAPING_MODE_FREETYPE shaping modes. Otherwise, it results in a question mark appearing in footnote number. This symbol is embedded in the text after the d2369334b610f75504bc80cc0697cc19314710f0 commit. See https://github.com/koreader/crengine/pull/385, https://github.com/koreader/koreader/issues/6718#issuecomment-699600019

FB3 support

• See #105 for details

WordML (docx) support

The following features are supported

• Basic formatting (bold,italic,underline,strike-through,subscript,superscript)
• Paragraph alignment
• Images (formats supported by crengine. i.e. no emf,wmf)
• Partially lists and tables
• Links, footnotes and endnotes

Open issues

• Advanced FB3 features such as SVG images, float property, extended description etc are not supported
• fb2.css was used for fb3 as is, probably some tweaks will be required for FB3
• Not much tested, https://github.com/gribuser/FB3/blob/master/Examples/Hardcore%20file%20structure.fb3 can't be opened.
• images having names like '%D0%BA%D0%BB%D0%B5%D1%82%D0%BA%D0%B0.jpg' in Anathomy tutorial example.fb3 also can't be opened (getObjectImageRefName() calls DecodeHTMLUrlString() which converts these %* chars, as a result the file can't be found in a zip file, not sure how to handle this caseproperly

Hi friends ,compiled version 3.2.58-1, I can’t find the TTS function, this exists in the windows version?Build under Windows (Using MSYS2),during installation, many libraries were not loaded from Yandex due to geo-blocking. Maybe because of this there is no TTS?

@virxkane @buggins

Hi it seems Buggins has disappeared and coolreader abandoned, I know @virxkane does not have access to produce compatible apk but I hope someone can create a github action to make apk so that people can merge commits and create their own apks till or if coolreader is ever revived.

I love coolreader. However, the Dutch (not German) translation has many errors. I would love to correct them. Please kindly provide the translation file, so I can provide proper translation. I'm unable to find the translation file, despite coolreader menu is able to show Dutch.