Please use this forum topic for comments about these releases.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2021-01-20
Please move to github or gitlab. I am trying to package your app to NixOS and I spend last hour trying to download the zip (programmatically) from SourceForge, so far unsuccessfully.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for reporting. I will have to look closely to see what is causing the issue.
The work-around is (you already use it in your example) :
Use hatch 45.001 2 (instead of hatch 45 2).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The origin of the issue is numerical precision. E.g. -8.9e-17 is not >= 0.0. Thus the intersection point of the (missing) hatch line is considered not to intersect the polygon section. Setting a tolerance for 0 (and 1) could solve the problem, but testing would be required to see whether the causes other issues ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I noticed that some quotation marks and Swedish letters are NOT "simple" lines in the Lines font, see attached image and hcl-file. I do hope that you can fix this.
(BTW the image is from the reMarkable)
It certainly is possible to fix this.
The lines fonts (plain and italic) are based on the publicly available "Hershey fonts". They cover English (Hershey fonts "rowmans" and "cursive"), Greek (Hershey font "greeks") and Russian letters and some symbols. They do not cover the Unicode groups Latin-1 or Latin-A. I have extended the glyph coverage for French, German, Italian (Latin-1), Latvian and Polish (Latin-A) languages. See the attached pdf files for Lines plain and Lines italic (implementation in the link).
Your example contains glyphs that are not implemented. What happens in such a case:
- fall back to "Lines plain" in case of "Lines italic"
- fall back to the last used Truetype font
I have implemented the line font because the reMarkable tablet does not support fills in the file format it uses for the notebooks. Thus only the outlines of Truetype fonts are rendered. The option was to mimic fills by close hatch lines, but this would result in a large file size. I have chosen to go the single line font way instead, but I have only implemented glyphs of languages I have to do with.
I am pleased there are a few other people using drawj2d to generate reMarkable notebook pages. It would be nice to extend the font coverage to more European languages and a few more mathematical symbols.
I will most likely have to limit my effort to the Latin-1 group. The Swedish letters of your example are not a big deal to implement (a circle above an existing glyph). For other "extended latin" glyphs or symbols I will be happy to accept contributions . If anybody is interested to do so, while it might be time consuming, it is not complicated (implementation linked above). There is a hcl-file that helps creating new glyphs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2021-03-15
Thanks for your contribution! I'll include it.
Maybe I'll use 12 polygon segments instead of 6 for the ring (same position and diameter).
Are there more missing letters for Swedish?
When using SVG-file even single path lines are draw as double lines when send to the reMarkable2 via rmapi. As I understand it the reMarkables notebook format can't handle filled areas, only lines, but with different widths.
See attach files, that will show the problem.
BTW, it only shows up incorrect when using "--type rmapi", it seems correct on other output types (I tried png, pdf and screen).
As I understand it the reMarkables notebook format can't handle filled areas, only lines, but with different widths.
Correct.
- The output types pdf, svg, eps, png, screen, emf, tikz and hcl support "fills".
- The output types bgd and rm|rmapi do not. A special case is dxf, as the file format supports fills (solid), but drawj2d has not implemented it.
Now, the best would be if reMarkable enhanced the file format. Support for the "fill" operation would also allow to properly render truetype fonts (outline glyphs).
Drawj2d (RemarkableGraphics2D.java) could implement an algorithm that fills polygons with lines. An approach would be to use and extend the existing hatch function. I'd expect rather bad results regarding the rendering of the line ends - or if choosing thin lines, the file size getting large. The device gets stuck when you try to select an area with many lines (this is the problem with raster images, e.g. image scan.png).
A better approach might be to draw parallel lines (polygons) at the inside of a polygon. But someone has to write the algorithm ... Not sure how difficult it would be to get it right for general cases (e.g. intersections, holes).
When using SVG-file even single path lines are draw as double lines ...
This seems to be the way svg are interpreted by the library svgSalamander. This probably could be changed (taking care not to break other output types), but someone would have to dig in that code.
To be honest, for me the double lines are not an issue I could spend much time on. But if anybody wants to tackle it I'll be open to accept contributions.
Thanks for reporting, regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have commited an (experimental) implementation to the subversion code repository. For reMarkable output (-T rm, -Trmapi, also -Tbgd) the command image drawing.svg will draw single lines with associated line widths instead of outlines.
Feel free to test it and report if it works for you. To compile you'll need javac and ant: just type ant in the main directory (where build.xml is).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ant
Buildfile: C:\Users\Stefan\Documents\reMarkable\Drawj2d\code\trunk\build.xml
init: [mkdir] Created dir:
C:\Users\Stefan\Documents\reMarkable\Drawj2d\code\trunk\build
compile: [javac] Compiling 1247 source files to
C:\Users\Stefan\Documents\reMarkable\Drawj2d\code\trunk\build [javac]
C:\Users\Stefan\Documents\reMarkable\Drawj2d\code\trunk\src\org\hecl\Interp.java:665:
error: invalid use of a restricted identifier 'yield' [javac] yield(); // give other thread a
chance [javac] ^ [javac] (to invoke a method called yield, qualify the yield with a
receiver or type name) [javac] 1 error
BUILD FAILED
C:\Users\Stefan\Documents\reMarkable\Drawj2d\code\trunk\build.xml:30:
Compile failed; see the compiler error output for details.
I have commited an (experimental) implementation to the subversion code
repository. For reMarkable output (-T rm, -Trmapi, also -Tbgd) the command image
drawing.svg will draw single lines with associated line widths instead of
outlines.
Feel free to test it and report if it works for you. To compile you'll
need javac and ant: just type ant in the main directory (where build.xml
is).
Ok, it seems the code has compatibility issues with Java 16. I currently use Java 11 - and Java 8 for the downloadable binaries (zip/rpm).
Please try if it compiles and runs when adding the line to build.xml: <compilerarg value="-J--illegal-access=permit"/>
between the lines <!--<compilerarg value="-Xlint"/>--> </javac>
Background: The Java 16 release notes mention Strongly Encapsulate JDK Internals by Default. Not sure whether the option --illegal-access=permit also must be added to java when running the program.
If it does not work as described above, please use Java 11 to build the program. And tell me if it then runs with Java 16 (or Java 11 only).
Thanks for your feedback.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The suggested changes to build.xml didn't help, still unable to build with
Java 16.
I uninstalled Java 16, and installed Java 11 instead, and now it compilers
and runs.
And is does no longer outline the lines, great work!
I did however notice that there seems to have happened something with the
overall scaling between 1.2.3 and 1.2.4(r310). See attached svg- and screen
captures (BTW it's a 5mm grid in the background for reference).
Notice how everything have been scaled down between the versions.
Ok, it seems the code has compatibility issues with Java 16. I currently
use Java 11 - and Java 8 for the downloadable binaries (zip/rpm).
Please try if it compiles and runs when adding the line to build.xml:
<compilerarg value="-J--illegal-access=permit">
between the lines
</compilerarg>
Background: The Java 16 release notes mention Strongly Encapsulate JDK
Internals by Default https://openjdk.java.net/jeps/396. Not sure
whether the option --illegal-access=permit also must be added to java
when running the program.
If it does not work as described above, please use Java 11 to build the
program. And tell me if it then runs with Java 16 (or Java 11 only).
Thanks for catching the scaling issue. I have commited [r311], it sets the assumed svg resolution to 96 dpi (same as drawj2d -Tsvg assumes when writing svg).
Please try again.
Thanks for catching the scaling issue. I have commited [r311] https://sourceforge.net/p/drawj2d/code/311/, it sets the assumed svg
resolution to 96 dpi (same as drawj2d -Tsvg assumes when writing svg).
Please try again.
Please use this forum topic for comments about these releases.
Please move to github or gitlab. I am trying to package your app to NixOS and I spend last hour trying to download the zip (programmatically) from SourceForge, so far unsuccessfully.
Does this work?
wget https://downloads.sourceforge.net/project/drawj2d/1.2.2/Drawj2d-1.2.2.zipI found an issue with hatchpolygon, where the hatching isn't complete.
For a small example that shows the problem, see attachments.
Thanks for reporting. I will have to look closely to see what is causing the issue.
The work-around is (you already use it in your example) :
Use
hatch 45.001 2(instead ofhatch 45 2).The origin of the issue is numerical precision. E.g. -8.9e-17 is not >= 0.0. Thus the intersection point of the (missing) hatch line is considered not to intersect the polygon section. Setting a tolerance for 0 (and 1) could solve the problem, but testing would be required to see whether the causes other issues ...
I have committed a fix r298 for the issue. It will be included in the next release (probably 1.2.3) if it won't cause any new issues.
Last edit: A. Vontobel 2021-03-14
Drawj2d 1.2.3 released.
I noticed that some quotation marks and Swedish letters are NOT "simple" lines in the Lines font, see attached image and hcl-file. I do hope that you can fix this.
(BTW the image is from the reMarkable)
It certainly is possible to fix this.
The lines fonts (plain and italic) are based on the publicly available "Hershey fonts". They cover English (Hershey fonts "rowmans" and "cursive"), Greek (Hershey font "greeks") and Russian letters and some symbols. They do not cover the Unicode groups Latin-1 or Latin-A. I have extended the glyph coverage for French, German, Italian (Latin-1), Latvian and Polish (Latin-A) languages. See the attached pdf files for Lines plain and Lines italic (implementation in the link).
Your example contains glyphs that are not implemented. What happens in such a case:
- fall back to "Lines plain" in case of "Lines italic"
- fall back to the last used Truetype font
I have implemented the line font because the reMarkable tablet does not support fills in the file format it uses for the notebooks. Thus only the outlines of Truetype fonts are rendered. The option was to mimic fills by close hatch lines, but this would result in a large file size. I have chosen to go the single line font way instead, but I have only implemented glyphs of languages I have to do with.
I am pleased there are a few other people using drawj2d to generate reMarkable notebook pages. It would be nice to extend the font coverage to more European languages and a few more mathematical symbols.
I will most likely have to limit my effort to the Latin-1 group. The Swedish letters of your example are not a big deal to implement (a circle above an existing glyph). For other "extended latin" glyphs or symbols I will be happy to accept contributions . If anybody is interested to do so, while it might be time consuming, it is not complicated (implementation linked above). There is a hcl-file that helps creating new glyphs.
How about these for the missing Swedish letters (åÅ)
..and here are the missing Swedish letters (åÅ) in italic.
Thanks for your contribution! I'll include it.
Maybe I'll use 12 polygon segments instead of 6 for the ring (same position and diameter).
Are there more missing letters for Swedish?
Last edit: A. Vontobel 2021-03-16
That looks great!
That will make all Swedish letters available!
Thanks, and keep up the good work!
I have commited the new glyphs to the subversion code repository. To compile it you'll need javac, svn and ant. Or wait for the next release.
Last edit: A. Vontobel 2021-03-17
Drawj2d 1.2.3 released. The Lines font now covers all the letters of the latin-1 group (a few symbols are not implemented though).
Found a bug :-(
When using SVG-file even single path lines are draw as double lines when send to the reMarkable2 via rmapi. As I understand it the reMarkables notebook format can't handle filled areas, only lines, but with different widths.
See attach files, that will show the problem.
BTW, it only shows up incorrect when using "--type rmapi", it seems correct on other output types (I tried png, pdf and screen).
I'm using drawj2d v1.23.
Last edit: Stefan Blixten Karlsson 2021-03-30
Let's call it a limitation :)
Correct.
- The output types pdf, svg, eps, png, screen, emf, tikz and hcl support "fills".
- The output types bgd and rm|rmapi do not. A special case is dxf, as the file format supports fills (solid), but drawj2d has not implemented it.
Now, the best would be if reMarkable enhanced the file format. Support for the "fill" operation would also allow to properly render truetype fonts (outline glyphs).
Drawj2d (RemarkableGraphics2D.java) could implement an algorithm that fills polygons with lines. An approach would be to use and extend the existing hatch function. I'd expect rather bad results regarding the rendering of the line ends - or if choosing thin lines, the file size getting large. The device gets stuck when you try to select an area with many lines (this is the problem with raster images, e.g.
image scan.png).A better approach might be to draw parallel lines (polygons) at the inside of a polygon. But someone has to write the algorithm ... Not sure how difficult it would be to get it right for general cases (e.g. intersections, holes).
This seems to be the way svg are interpreted by the library svgSalamander. This probably could be changed (taking care not to break other output types), but someone would have to dig in that code.
To be honest, for me the double lines are not an issue I could spend much time on. But if anybody wants to tackle it I'll be open to accept contributions.
Thanks for reporting, regards
I have commited an (experimental) implementation to the subversion code repository. For reMarkable output (-T rm, -Trmapi, also -Tbgd) the command
image drawing.svgwill draw single lines with associated line widths instead of outlines.Feel free to test it and report if it works for you. To compile you'll need javac and ant: just type
antin the main directory (where build.xml is).Tried to build it, but got "BUILD FAILED" !
See console output below:
C:\Users\Stefan\Documents\reMarkable\Drawj2d\code\trunk
C:\Users\Stefan\Documents\reMarkable\Drawj2d\code\trunk
C:\Users\Stefan\Documents\reMarkable\Drawj2d\code\trunk
C:\Users\Stefan\Documents\reMarkable\Drawj2d\code\trunk
init:
[mkdir] Created dir:
C:\Users\Stefan\Documents\reMarkable\Drawj2d\code\trunk\build
compile:
[javac] Compiling 1247 source files to
C:\Users\Stefan\Documents\reMarkable\Drawj2d\code\trunk\build
[javac]
C:\Users\Stefan\Documents\reMarkable\Drawj2d\code\trunk\src\org\hecl\Interp.java:665:
error: invalid use of a restricted identifier 'yield'
[javac] yield(); // give other thread a
chance
[javac] ^
[javac] (to invoke a method called yield, qualify the yield with a
receiver or type name)
[javac] 1 error
BUILD FAILED
C:\Users\Stefan\Documents\reMarkable\Drawj2d\code\trunk\build.xml:30:
Compile failed; see the compiler error output for details.
Total time: 4 seconds
C:\Users\Stefan\Documents\reMarkable\Drawj2d\code\trunk
Den lör 10 apr. 2021 kl 17:08 skrev A. Vontobel qwert2003@users.sourceforge.net:
Ok, it seems the code has compatibility issues with Java 16. I currently use Java 11 - and Java 8 for the downloadable binaries (zip/rpm).
Please try if it compiles and runs when adding the line to build.xml:
<compilerarg value="-J--illegal-access=permit"/>between the lines
<!--<compilerarg value="-Xlint"/>--></javac>Background: The Java 16 release notes mention Strongly Encapsulate JDK Internals by Default. Not sure whether the option
--illegal-access=permitalso must be added to java when running the program.If it does not work as described above, please use Java 11 to build the program. And tell me if it then runs with Java 16 (or Java 11 only).
Thanks for your feedback.
The suggested changes to build.xml didn't help, still unable to build with
Java 16.
I uninstalled Java 16, and installed Java 11 instead, and now it compilers
and runs.
And is does no longer outline the lines, great work!
I did however notice that there seems to have happened something with the
overall scaling between 1.2.3 and 1.2.4(r310). See attached svg- and screen
captures (BTW it's a 5mm grid in the background for reference).
Notice how everything have been scaled down between the versions.
/Stefan
Den sön 11 apr. 2021 kl 00:32 skrev A. Vontobel qwert2003@users.sourceforge.net:
Thanks for catching the scaling issue. I have commited [r311], it sets the assumed svg resolution to 96 dpi (same as drawj2d -Tsvg assumes when writing svg).
Please try again.
Related
Commit: [r311]
Now also the scaling seems to works.
Great work!
Den sön 11 apr. 2021 kl 11:03 skrev A. Vontobel qwert2003@users.sourceforge.net:
Related
Commit: [r311]
...yes, limitation is a better name...
...but in this case there should NOT be any "fill", it should only be a lines a round the perimeter.
So, why is it then a double line ?