JDK-8227767 : Generated HTML JavaDoc should have the same font as the JDK docs
  • Type: Bug
  • Component: javafx
  • Sub-Component: other
  • Affected Version: openjfx13
  • Priority: P5
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2019-07-16
  • Updated: 2019-08-10
  • Resolved: 2019-08-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
openjfx13Resolved
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Description
The JDK docs use a more readable font for the generated HTML pages. JavaFX should use this font as well.
Comments
I think this issue can be closed as a duplicate of the other two, unless there is some follow-on work to track separately.
08-08-2019

I filed 2 P5 issues: 1. JDK-8229190 assigned to [~jvos]. If he's not willing to do this he can close it as Won't Fix. 2. JDK-8229200 assigned to [~kcr].
06-08-2019

In that case we probably want to split this into two issues: [~jvos] would take the first one (if he is willing to do this). Yes, I suspect that updating the existing JavaFX 11 online docs would be easy once done for JavaFX 13. I would take the second, since it would either involved third-party legal approval (to check the files into the repo), or else build changes to accept a parameter that points to an external location where the fonts are located.
02-08-2019

I agree. #1 is simpler and should be done at least for 13 (I assume that if it's done once, doing it for previous versions is easy). #2 requires someone who knows where the fonts are being looked for and how the correct formats are generated. I'm not familiar with any of this.
27-07-2019

I can see two possible approaches: 1. Fix this on the hosting site for the online JavaFX docs. This would involve having Johan overlay a dejavu.css file along with the DejaVu fonts when staging them on the docs site when the release ships. The upside is that this could still be done for JavaFX 13 (it could even be done retroactively for the JavaFX 12 docs if desired). The drawback is that anyone building the docs themselves or downloading the .zip budle of the docs wouldn't get the fix. Also, it requires some manual work (although it could probably be scripted) for each release. 2. Deliver the fonts as part of the build. This is out of scope for openjfx13 and would require legal approval for anything checked into the repo. While I think #2 might be something to consider for the long term, #1 is the only possible way to do anything in the JavaFX 13 time frame (and doesn't preclude the second option being done later).
26-07-2019

favicon.ico is a completely separate file and is nothing to do with fonts. The next step is to get the right font files for the DejaVu font, in the right format, along with a dejavu.css file that points at those font files. I note that you can also find font files in TTF format if you want to use those instead.
23-07-2019

I don't know much more about this, it's server configuration stuff. I found https://hotcakescommerce.zendesk.com/hc/en-us/articles/210926903-HTTP-404-Not-Found-Error-with-woff-or-woff2-Font-Files Maybe a hint is that the favicon.ico file is also not found. I don't know where it should come from.
23-07-2019

[~jjg] Thanks for the reply. I added [~jvos] as a watcher on this bug. Once we know what needs to be done, Gluon would likely need to install the fonts on openjfx.io.
22-07-2019

[~nlisker] I don't know where the .woff files in Oracle JDK originally came from, but I do see there are format converters available "out there". Here is one such, as an example. https://everythingfonts.com/sfd-to-woff (No recommendation implied or intended.) javadoc does not handle anything to do with installing the DejaVu fonts. It merely references them if they are available. I don't know if the server has to do anything special with the files, as long as they installed in "the right place" relative to the API docs, such that any references to those files "just work". As I read it, dejavu.css is just a text file that is referenced in the main stylesheet, and which lists the fonts (if any) in the DejaVu family that are available in the same directory.
21-07-2019

[~jjg] If I install them locally it works, but the server is supposed to supply them, I think, because they are used correctly in the OpenJDK docs pages even when not installed locally. So the question now is how the server is setup to be able to deliver them. The dejavu.css references .woff files that were not available for download. Furthermore, even after installing the fonts, the javadoc generation task still does not create the resources/fonts/dejavu.css file, so I'm not sure what's missing.
21-07-2019

See https://en.wikipedia.org/wiki/DejaVu_fonts https://github.com/dejavu-fonts/dejavu-fonts
21-07-2019

The issue is that the browser can't load the dejavu font and returns an error: Failed to load resource: the server responded with a status of 404 () dejavu.css:1 Under javadoc/resources there is the path /fonts/dejavu.css in the OpenJDK site, but not in the OpenJFX one. There are other similar errors: Failed to load resource: the server responded with a status of 404 () /javadoc/12/tag-search-index.js:1 Failed to load resource: the server responded with a status of 404 () /favicon.ico:1
17-07-2019