Closed jacekiwaszko1 closed 8 months ago
The same applies to segno and coda markings:
test data:
**kern
!!LO:TX:t=[segno]
1c
=
!!LO:TX:t=[coda]
1d
==
*-
VHV:
PDF export:
This is some sort of font problem, where the original font (such as Leipzig, Bravura, Leland) is not found by the PDF display software, so it substitutes another font and displays what character number is the same as the original. For the Chinese characters, they happen to be the same codepoint as the equivalent codepoint for the missing music font. For the last case, there is nothing at that codepoint in the substitution font, so it is drawing an empty box.
On my computer, the PDF displays properly in the PDF viewer built into the Chrome browser:
Checking with Preview.app in MacOS:
Using pdffonts
, it says that the Leipzig font is included in the PDF file:
(And Leipzig is the music font selected in VHV, which should not require any SMuFL font overlays for missing glyphs).
How does the downloaded PDF look in MacOS for you compared to linux (in which you are probably viewing the above examples).
I do not have Leipzig or other SMuFL fonts (at least Leipzig, Bravura, or Leland) installed in my MacOS system fonts:
system_profiler SPFontsDataType | grep "Full Name" | sort
So the most likely problem is that the PDF viewer you are using is not reading the embedded fonts. Notice that my "sempre" and your "sempre" are using a different font. The PDF file contains EBGaramond Italic, and you version is not using that font as well (perhaps substituting Times Italic for EBGaramond Italic).
I did some tests on different OSes, and I can't get the proper output in PDF.
Here's the output of pdffonts
for the three PDF files exported from VHV on Linux, Mac and Windows systems:
I am wondering, if it's some kind of Chrome setting which prevents Leipzig font from being embedded in the PDF file, or it's something else?
Here is an example of using Petaluma font:
The downloaded PDF has font problems:
pdffonts
does not list any SMuFL fonts (particularly petaluma:
Leland font:
Bravura:
Gootville:
Leipzig:
So the problem is that only when Leipzig is being used will it be included in the PDF. Gootville is a strange exception, where Leipzig is being added to the PDF rather than Gootville (but the PDF viewer does not know to substiute Leipzig for Gootville).
The Gootville example includes the half note symbol correctly, but not the p
. This is probably due to a font overlay being used: The Gootville font probably does not have the half-note symbol (for inline text), and Leipzig is being used instead.
You are using Leland font, which has the font-inclusion problem in the PDF.
That is something that I should be able to fix. Probably I only consider including Leipzig when creating the PDF. If I check what the active music font is instead of just adding Leipzig, the problem may be fixed.
The PDF seems to automatically include only the fonts that it sees are being used in the PDF, so if I include all music font, that might be the best solution, and the PDFKit software will only add the fonts that are actually used.
I load all SMuFL music fonts before creating PDFs now, and the needed fonts are included in the PDF now:
Bravura:
Gootville:
Note in this case Leipzig and Gootville are both added because the half note is coming from Leipzig (but it does not look the same as the SVG version in VHV).
Leipzig (as originally):
Leland:
Petaluma:
Substitution of dynamics linked with text (eg. p sempre) and note symbols in metronome notation are not converted in PDF export correctly.
Example data:
click to see MEI conversion
```xmlTranscoded from Humdrum
VHV rendering:
VHV PDF export:
Command-line Verovio export: