Skip to content

Fix getting the fd index for OTF/CFF CID fonts - #207

Merged
devongovett merged 1 commit into
foliojs:masterfrom
blikblum:fix-cff-cid
Nov 17, 2019
Merged

Fix getting the fd index for OTF/CFF CID fonts#207
devongovett merged 1 commit into
foliojs:masterfrom
blikblum:fix-cff-cid

Conversation

@blikblum

@blikblumblikblum commented Oct 5, 2019

Copy link
Copy Markdown
Member

There's a logic error in the binary search that looks for fd index in CFFFont#fdForGlyph leading to erroneous result when gid is exactly equal to range.first.

To see the bug load a CID font like NotoSansCJKkr-Regular.otf in https://fontkit-demo.now.sh/ and try to draw character ":" (gid 27)

Its possible to optimize the binary search a bit but will let this for later, just get the minimal change to fix the bug

This was referenced Oct 5, 2019
Open
Closed
@blikblumblikblum mentioned this pull request Nov 13, 2019
Closed
@devongovett
devongovett merged commit cebf94e into foliojs:masterNov 17, 2019
@Harbs

Harbs commented Nov 17, 2019

Copy link
Copy Markdown

I think this fix is functionally equivalent to pull #168.

You can probably either use that fix, or close the PR. FWIW, I think my fix is slightly more efficient (bails slightly earlier).

@blikblum

blikblum commented Nov 17, 2019

Copy link
Copy Markdown
MemberAuthor

You can probably either use that fix, or close the PR. FWIW, I think my fix is slightly more efficient (bails slightly earlier).

Yes. I used the minimal change needed approach to fix it. One advantage of this PR is that contain tests but i agree that your fix is (probably) better performance wise.

I suggest you to rebase your PR on top of current master and run the tests to ensure all clear

@ghislain-sc

ghislain-sc commented Jan 14, 2020

Copy link
Copy Markdown

I tried implementing this fix into the standalone version of PDF kit, the problem still appears with Noto Sans SC and Chinese punctuation marks.

The glyphs.js doesn't seem to be included in the standalone version, do I need to include it?

@blikblum

blikblum commented Jan 14, 2020

Copy link
Copy Markdown
MemberAuthor

I tried implementing this fix into the standalone version of PDF kit, the problem still appears with Noto Sans SC and Chinese punctuation marks.

Can you try https://www.npmjs.com/package/pdfkit-next ? It comes with this fix

@ghislain-sc

ghislain-sc commented Jan 14, 2020•
edited
Loading

Copy link
Copy Markdown

I looked into that earlier today, but I wasn't able to compile the next package into a standalone version. (I tried locally on Mac).

I'll try again.

@blikblum

blikblum commented Jan 14, 2020

Copy link
Copy Markdown
MemberAuthor

Try https://unpkg.com/pdfkit-next@0.10.0/js/pdfkit.standalone.js

@ghislain-sc

ghislain-sc commented Jan 14, 2020

Copy link
Copy Markdown

I just tried, using the mac terminal to install "pdfkit-next", then uploading the "pdfkit.standalone.js" located in the "pdfkit-next" folder. But no improvements.

@ghislain-sc

ghislain-sc commented Jan 14, 2020

Copy link
Copy Markdown

Try https://unpkg.com/pdfkit-next@0.10.0/js/pdfkit.standalone.js

Thank you. Just tried it and no improvements.

@blikblum

blikblum commented Jan 14, 2020

Copy link
Copy Markdown
MemberAuthor

What font are you using?
What text do you get an error?

@blikblum

blikblum commented Jan 14, 2020

Copy link
Copy Markdown
MemberAuthor

This repl it shows correct output with pdfkit-next: https://repl.it/@blikblum/pdfkit-notosans

When using published pdfkit package, there are errors

@blikblumblikblum mentioned this pull request Feb 20, 2020
Closed
@ghislain-sc

ghislain-sc commented May 8, 2020

Copy link
Copy Markdown

Hi, sorry for the long delay.

To answer your question: I was using Noto Sans SC. I tried all font weights, tried unhinted, hinted, tried converting it to TTF, use OTF. Also tried Adobe Source Han Sans (which is the exact same font) available in OTF and TTF...

The problem always appears when the text include punctuation, wether Chinese or English. The problem might occur before the punctuation or after. When rendering a paragraph without punctuation, there is no problem. Example of punctuation creating problems: ()" ' , ; : 。，：“ ‘ （）「」...

After several attempts I had settled for a half solution, back in January: I used Noto for all Chinese characters and switched to PingFang for Chinese punctuation. In order to do so, I checked each character with .match(/[\x20-\x7E]/) and .match(/[\u3400-\u9FBF]/).

This solution was less than ideal, it meant a lot of processing for every single paragraph. Even the font switch wasn't that noticeable since I used Pingfang only for special characters, it was still disturbing enough. Finally the PDFs generated were fine in the browser and most preview apps, but appeared broken when open with Adobe Acrobat. So we just stopped.

In the end we just gave up the idea of generating PDFs from our website. But today I noticed the comments and so I gave a look at the repl it. Actually the problem still shows with the Noto font PDF. As you can see the second line should read "产品名:", but it shows only "产 :"

The mistake appears far enough to be too noticeable, which is probably why you thought it was fixed. Then I ran the repl it with a complete paragraph, including more special characters. And the problem is still definitely here.

We don't have immediate use for this anymore, but I believe other people might. I'll try to check this thread more often, let me know if you need more details. Thank you.

@ghislain-sc

ghislain-sc commented May 18, 2020

Copy link
Copy Markdown

Hi, for anyone looking to use this specific font Noto Sans SC / TC with PDF Kit, there is actually a workaround. Google's Noto Sans SC and Adobe's Source Han SC are actually the same font, made by the same designer. And there is a TTF version of Adobe's version here: https://github.com/Pal3love/Source-Han-TrueType

Once using this file, everything works well.

@t6adevt6adev mentioned this pull request Dec 19, 2020
Closed
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@devongovettdevongovettdevongovett approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@blikblum@Harbs@ghislain-sc@devongovett
, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Fix getting the fd index for OTF/CFF CID fonts by blikblum · Pull Request #207 · foliojs/fontkit · GitHub
Skip to content
Fix getting the fd index for OTF/CFF CID fonts - #207
Merged
devongovett merged 1 commit into
foliojs:masterfrom 
blikblum:fix-cff-cid
Nov 17, 2019
Merged
Fix getting the fd index for OTF/CFF CID fonts#207
devongovett merged 1 commit into
foliojs:masterfrom 
blikblum:fix-cff-cid
Conversation
@blikblum
@blikblumblikblum
commented
Oct 5, 2019

Copy link


Copy Markdown

Member
There's a logic error in the binary search that looks for fd index in CFFFont#fdForGlyph leading to erroneous result when gid is exactly equal to range.first.
To see the bug load a CID font like NotoSansCJKkr-Regular.otf in https://fontkit-demo.now.sh/ and try to draw character ":" (gid 27)
Its possible to optimize the binary search a bit but will let this for later, just get the minimal change to fix the bug

This was referenced Oct 5, 2019

Open


Closed

@blikblumblikblum
mentioned this pull request
Nov 13, 2019

Closed

@devongovett
devongovett
merged commit cebf94e
into
foliojs:masterNov 17, 2019
@Harbs
Harbs
commented
Nov 17, 2019

Copy link


Copy Markdown

I think this fix is functionally equivalent to pull #168.
You can probably either use that fix, or close the PR. FWIW, I think my fix is slightly more efficient (bails slightly earlier).
@blikblum
blikblum
commented
Nov 17, 2019

Copy link


Copy Markdown

MemberAuthor
You can probably either use that fix, or close the PR. FWIW, I think my fix is slightly more efficient (bails slightly earlier).
Yes. I used the minimal change needed approach to fix it. One advantage of this PR is that contain tests but i agree that your fix is (probably) better performance wise.
I suggest you to rebase your PR on top of current master and run the tests to ensure all clear
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020

Copy link


Copy Markdown

I tried implementing this fix into the standalone version of PDF kit, the problem still appears with Noto Sans SC and Chinese punctuation marks.
The glyphs.js doesn't seem to be included in the standalone version, do I need to include it?
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
I tried implementing this fix into the standalone version of PDF kit, the problem still appears with Noto Sans SC and Chinese punctuation marks.
Can you try https://www.npmjs.com/package/pdfkit-next ? It comes with this fix
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020•

edited

Loading

Copy link


Copy Markdown

I looked into that earlier today, but I wasn't able to compile the next package into a standalone version. (I tried locally on Mac).
I'll try again.
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
Try https://unpkg.com/pdfkit-next@0.10.0/js/pdfkit.standalone.js
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020

Copy link


Copy Markdown

I just tried, using the mac terminal to install "pdfkit-next", then uploading the "pdfkit.standalone.js" located in the "pdfkit-next" folder. But no improvements.
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020

Copy link


Copy Markdown

Try https://unpkg.com/pdfkit-next@0.10.0/js/pdfkit.standalone.js
Thank you. Just tried it and no improvements.
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
What font are you using?

What text do you get an error?
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
This repl it shows correct output with pdfkit-next: https://repl.it/@blikblum/pdfkit-notosans
When using published pdfkit package, there are errors
@blikblumblikblum
mentioned this pull request
Feb 20, 2020
 Closed

@ghislain-sc
ghislain-sc
commented
May 8, 2020

Copy link


Copy Markdown

Hi, sorry for the long delay.
To answer your question: I was using Noto Sans SC. I tried all font weights, tried unhinted, hinted, tried converting it to TTF, use OTF. Also tried Adobe Source Han Sans (which is the exact same font) available in OTF and TTF...
The problem always appears when the text include punctuation, wether Chinese or English. The problem might occur before the punctuation or after. When rendering a paragraph without punctuation, there is no problem. Example of punctuation creating problems: ()" ' , ; : 。，：“ ‘ （）「」...
After several attempts I had settled for a half solution, back in January: I used Noto for all Chinese characters and switched to PingFang for Chinese punctuation. In order to do so, I checked each character with .match(/[\x20-\x7E]/) and .match(/[\u3400-\u9FBF]/).
This solution was less than ideal, it meant a lot of processing for every single paragraph. Even the font switch wasn't that noticeable since I used Pingfang only for special characters, it was still disturbing enough. Finally the PDFs generated were fine in the browser and most preview apps, but appeared broken when open with Adobe Acrobat. So we just stopped.
In the end we just gave up the idea of generating PDFs from our website. But today I noticed the comments and so I gave a look at the repl it. Actually the problem still shows with the Noto font PDF. As you can see the second line should read "产品名:", but it shows only "产 :"
The mistake appears far enough to be too noticeable, which is probably why you thought it was fixed. Then I ran the repl it with a complete paragraph, including more special characters. And the problem is still definitely here.
We don't have immediate use for this anymore, but I believe other people might. I'll try to check this thread more often, let me know if you need more details. Thank you.
@ghislain-sc
ghislain-sc
commented
May 18, 2020

Copy link


Copy Markdown

Hi, for anyone looking to use this specific font Noto Sans SC / TC with PDF Kit, there is actually a workaround. Google's Noto Sans SC and Adobe's Source Han SC are actually the same font, made by the same designer. And there is a TTF version of Adobe's version here: https://github.com/Pal3love/Source-Han-TrueType
Once using this file, everything works well.
@t6adevt6adev
mentioned this pull request
Dec 19, 2020

Closed

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@devongovettdevongovettdevongovett approved these changes

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

4 participants

@blikblum@Harbs@ghislain-sc@devongovett

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Fix getting the fd index for OTF/CFF CID fonts by blikblum · Pull Request #207 · foliojs/fontkit · GitHub
Skip to content
Fix getting the fd index for OTF/CFF CID fonts - #207
Merged
devongovett merged 1 commit into
foliojs:masterfrom 
blikblum:fix-cff-cid
Nov 17, 2019
Merged
Fix getting the fd index for OTF/CFF CID fonts#207
devongovett merged 1 commit into
foliojs:masterfrom 
blikblum:fix-cff-cid
Conversation
@blikblum
@blikblumblikblum
commented
Oct 5, 2019

Copy link


Copy Markdown

Member
There's a logic error in the binary search that looks for fd index in CFFFont#fdForGlyph leading to erroneous result when gid is exactly equal to range.first.
To see the bug load a CID font like NotoSansCJKkr-Regular.otf in https://fontkit-demo.now.sh/ and try to draw character ":" (gid 27)
Its possible to optimize the binary search a bit but will let this for later, just get the minimal change to fix the bug

This was referenced Oct 5, 2019

Open


Closed

@blikblumblikblum
mentioned this pull request
Nov 13, 2019

Closed

@devongovett
devongovett
merged commit cebf94e
into
foliojs:masterNov 17, 2019
@Harbs
Harbs
commented
Nov 17, 2019

Copy link


Copy Markdown

I think this fix is functionally equivalent to pull #168.
You can probably either use that fix, or close the PR. FWIW, I think my fix is slightly more efficient (bails slightly earlier).
@blikblum
blikblum
commented
Nov 17, 2019

Copy link


Copy Markdown

MemberAuthor
You can probably either use that fix, or close the PR. FWIW, I think my fix is slightly more efficient (bails slightly earlier).
Yes. I used the minimal change needed approach to fix it. One advantage of this PR is that contain tests but i agree that your fix is (probably) better performance wise.
I suggest you to rebase your PR on top of current master and run the tests to ensure all clear
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020

Copy link


Copy Markdown

I tried implementing this fix into the standalone version of PDF kit, the problem still appears with Noto Sans SC and Chinese punctuation marks.
The glyphs.js doesn't seem to be included in the standalone version, do I need to include it?
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
I tried implementing this fix into the standalone version of PDF kit, the problem still appears with Noto Sans SC and Chinese punctuation marks.
Can you try https://www.npmjs.com/package/pdfkit-next ? It comes with this fix
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020•

edited

Loading

Copy link


Copy Markdown

I looked into that earlier today, but I wasn't able to compile the next package into a standalone version. (I tried locally on Mac).
I'll try again.
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
Try https://unpkg.com/pdfkit-next@0.10.0/js/pdfkit.standalone.js
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020

Copy link


Copy Markdown

I just tried, using the mac terminal to install "pdfkit-next", then uploading the "pdfkit.standalone.js" located in the "pdfkit-next" folder. But no improvements.
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020

Copy link


Copy Markdown

Try https://unpkg.com/pdfkit-next@0.10.0/js/pdfkit.standalone.js
Thank you. Just tried it and no improvements.
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
What font are you using?

What text do you get an error?
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
This repl it shows correct output with pdfkit-next: https://repl.it/@blikblum/pdfkit-notosans
When using published pdfkit package, there are errors
@blikblumblikblum
mentioned this pull request
Feb 20, 2020
 Closed

@ghislain-sc
ghislain-sc
commented
May 8, 2020

Copy link


Copy Markdown

Hi, sorry for the long delay.
To answer your question: I was using Noto Sans SC. I tried all font weights, tried unhinted, hinted, tried converting it to TTF, use OTF. Also tried Adobe Source Han Sans (which is the exact same font) available in OTF and TTF...
The problem always appears when the text include punctuation, wether Chinese or English. The problem might occur before the punctuation or after. When rendering a paragraph without punctuation, there is no problem. Example of punctuation creating problems: ()" ' , ; : 。，：“ ‘ （）「」...
After several attempts I had settled for a half solution, back in January: I used Noto for all Chinese characters and switched to PingFang for Chinese punctuation. In order to do so, I checked each character with .match(/[\x20-\x7E]/) and .match(/[\u3400-\u9FBF]/).
This solution was less than ideal, it meant a lot of processing for every single paragraph. Even the font switch wasn't that noticeable since I used Pingfang only for special characters, it was still disturbing enough. Finally the PDFs generated were fine in the browser and most preview apps, but appeared broken when open with Adobe Acrobat. So we just stopped.
In the end we just gave up the idea of generating PDFs from our website. But today I noticed the comments and so I gave a look at the repl it. Actually the problem still shows with the Noto font PDF. As you can see the second line should read "产品名:", but it shows only "产 :"
The mistake appears far enough to be too noticeable, which is probably why you thought it was fixed. Then I ran the repl it with a complete paragraph, including more special characters. And the problem is still definitely here.
We don't have immediate use for this anymore, but I believe other people might. I'll try to check this thread more often, let me know if you need more details. Thank you.
@ghislain-sc
ghislain-sc
commented
May 18, 2020

Copy link


Copy Markdown

Hi, for anyone looking to use this specific font Noto Sans SC / TC with PDF Kit, there is actually a workaround. Google's Noto Sans SC and Adobe's Source Han SC are actually the same font, made by the same designer. And there is a TTF version of Adobe's version here: https://github.com/Pal3love/Source-Han-TrueType
Once using this file, everything works well.
@t6adevt6adev
mentioned this pull request
Dec 19, 2020

Closed

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@devongovettdevongovettdevongovett approved these changes

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

4 participants

@blikblum@Harbs@ghislain-sc@devongovett

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Fix getting the fd index for OTF/CFF CID fonts by blikblum · Pull Request #207 · foliojs/fontkit · GitHub
Skip to content
Fix getting the fd index for OTF/CFF CID fonts - #207
Merged
devongovett merged 1 commit into
foliojs:masterfrom 
blikblum:fix-cff-cid
Nov 17, 2019
Merged
Fix getting the fd index for OTF/CFF CID fonts#207
devongovett merged 1 commit into
foliojs:masterfrom 
blikblum:fix-cff-cid
Conversation
@blikblum
@blikblumblikblum
commented
Oct 5, 2019

Copy link


Copy Markdown

Member
There's a logic error in the binary search that looks for fd index in CFFFont#fdForGlyph leading to erroneous result when gid is exactly equal to range.first.
To see the bug load a CID font like NotoSansCJKkr-Regular.otf in https://fontkit-demo.now.sh/ and try to draw character ":" (gid 27)
Its possible to optimize the binary search a bit but will let this for later, just get the minimal change to fix the bug

This was referenced Oct 5, 2019

Open


Closed

@blikblumblikblum
mentioned this pull request
Nov 13, 2019

Closed

@devongovett
devongovett
merged commit cebf94e
into
foliojs:masterNov 17, 2019
@Harbs
Harbs
commented
Nov 17, 2019

Copy link


Copy Markdown

I think this fix is functionally equivalent to pull #168.
You can probably either use that fix, or close the PR. FWIW, I think my fix is slightly more efficient (bails slightly earlier).
@blikblum
blikblum
commented
Nov 17, 2019

Copy link


Copy Markdown

MemberAuthor
You can probably either use that fix, or close the PR. FWIW, I think my fix is slightly more efficient (bails slightly earlier).
Yes. I used the minimal change needed approach to fix it. One advantage of this PR is that contain tests but i agree that your fix is (probably) better performance wise.
I suggest you to rebase your PR on top of current master and run the tests to ensure all clear
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020

Copy link


Copy Markdown

I tried implementing this fix into the standalone version of PDF kit, the problem still appears with Noto Sans SC and Chinese punctuation marks.
The glyphs.js doesn't seem to be included in the standalone version, do I need to include it?
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
I tried implementing this fix into the standalone version of PDF kit, the problem still appears with Noto Sans SC and Chinese punctuation marks.
Can you try https://www.npmjs.com/package/pdfkit-next ? It comes with this fix
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020•

edited

Loading

Copy link


Copy Markdown

I looked into that earlier today, but I wasn't able to compile the next package into a standalone version. (I tried locally on Mac).
I'll try again.
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
Try https://unpkg.com/pdfkit-next@0.10.0/js/pdfkit.standalone.js
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020

Copy link


Copy Markdown

I just tried, using the mac terminal to install "pdfkit-next", then uploading the "pdfkit.standalone.js" located in the "pdfkit-next" folder. But no improvements.
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020

Copy link


Copy Markdown

Try https://unpkg.com/pdfkit-next@0.10.0/js/pdfkit.standalone.js
Thank you. Just tried it and no improvements.
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
What font are you using?

What text do you get an error?
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
This repl it shows correct output with pdfkit-next: https://repl.it/@blikblum/pdfkit-notosans
When using published pdfkit package, there are errors
@blikblumblikblum
mentioned this pull request
Feb 20, 2020
 Closed

@ghislain-sc
ghislain-sc
commented
May 8, 2020

Copy link


Copy Markdown

Hi, sorry for the long delay.
To answer your question: I was using Noto Sans SC. I tried all font weights, tried unhinted, hinted, tried converting it to TTF, use OTF. Also tried Adobe Source Han Sans (which is the exact same font) available in OTF and TTF...
The problem always appears when the text include punctuation, wether Chinese or English. The problem might occur before the punctuation or after. When rendering a paragraph without punctuation, there is no problem. Example of punctuation creating problems: ()" ' , ; : 。，：“ ‘ （）「」...
After several attempts I had settled for a half solution, back in January: I used Noto for all Chinese characters and switched to PingFang for Chinese punctuation. In order to do so, I checked each character with .match(/[\x20-\x7E]/) and .match(/[\u3400-\u9FBF]/).
This solution was less than ideal, it meant a lot of processing for every single paragraph. Even the font switch wasn't that noticeable since I used Pingfang only for special characters, it was still disturbing enough. Finally the PDFs generated were fine in the browser and most preview apps, but appeared broken when open with Adobe Acrobat. So we just stopped.
In the end we just gave up the idea of generating PDFs from our website. But today I noticed the comments and so I gave a look at the repl it. Actually the problem still shows with the Noto font PDF. As you can see the second line should read "产品名:", but it shows only "产 :"
The mistake appears far enough to be too noticeable, which is probably why you thought it was fixed. Then I ran the repl it with a complete paragraph, including more special characters. And the problem is still definitely here.
We don't have immediate use for this anymore, but I believe other people might. I'll try to check this thread more often, let me know if you need more details. Thank you.
@ghislain-sc
ghislain-sc
commented
May 18, 2020

Copy link


Copy Markdown

Hi, for anyone looking to use this specific font Noto Sans SC / TC with PDF Kit, there is actually a workaround. Google's Noto Sans SC and Adobe's Source Han SC are actually the same font, made by the same designer. And there is a TTF version of Adobe's version here: https://github.com/Pal3love/Source-Han-TrueType
Once using this file, everything works well.
@t6adevt6adev
mentioned this pull request
Dec 19, 2020

Closed

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@devongovettdevongovettdevongovett approved these changes

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

4 participants

@blikblum@Harbs@ghislain-sc@devongovett

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '
Fix getting the fd index for OTF/CFF CID fonts by blikblum · Pull Request #207 · foliojs/fontkit · GitHub
Skip to content
Fix getting the fd index for OTF/CFF CID fonts - #207
Merged
devongovett merged 1 commit into
foliojs:masterfrom 
blikblum:fix-cff-cid
Nov 17, 2019
Merged
Fix getting the fd index for OTF/CFF CID fonts#207
devongovett merged 1 commit into
foliojs:masterfrom 
blikblum:fix-cff-cid
Conversation
@blikblum
@blikblumblikblum
commented
Oct 5, 2019

Copy link


Copy Markdown

Member
There's a logic error in the binary search that looks for fd index in CFFFont#fdForGlyph leading to erroneous result when gid is exactly equal to range.first.
To see the bug load a CID font like NotoSansCJKkr-Regular.otf in https://fontkit-demo.now.sh/ and try to draw character ":" (gid 27)
Its possible to optimize the binary search a bit but will let this for later, just get the minimal change to fix the bug

This was referenced Oct 5, 2019

Open


Closed

@blikblumblikblum
mentioned this pull request
Nov 13, 2019

Closed

@devongovett
devongovett
merged commit cebf94e
into
foliojs:masterNov 17, 2019
@Harbs
Harbs
commented
Nov 17, 2019

Copy link


Copy Markdown

I think this fix is functionally equivalent to pull #168.
You can probably either use that fix, or close the PR. FWIW, I think my fix is slightly more efficient (bails slightly earlier).
@blikblum
blikblum
commented
Nov 17, 2019

Copy link


Copy Markdown

MemberAuthor
You can probably either use that fix, or close the PR. FWIW, I think my fix is slightly more efficient (bails slightly earlier).
Yes. I used the minimal change needed approach to fix it. One advantage of this PR is that contain tests but i agree that your fix is (probably) better performance wise.
I suggest you to rebase your PR on top of current master and run the tests to ensure all clear
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020

Copy link


Copy Markdown

I tried implementing this fix into the standalone version of PDF kit, the problem still appears with Noto Sans SC and Chinese punctuation marks.
The glyphs.js doesn't seem to be included in the standalone version, do I need to include it?
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
I tried implementing this fix into the standalone version of PDF kit, the problem still appears with Noto Sans SC and Chinese punctuation marks.
Can you try https://www.npmjs.com/package/pdfkit-next ? It comes with this fix
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020•

edited

Loading

Copy link


Copy Markdown

I looked into that earlier today, but I wasn't able to compile the next package into a standalone version. (I tried locally on Mac).
I'll try again.
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
Try https://unpkg.com/pdfkit-next@0.10.0/js/pdfkit.standalone.js
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020

Copy link


Copy Markdown

I just tried, using the mac terminal to install "pdfkit-next", then uploading the "pdfkit.standalone.js" located in the "pdfkit-next" folder. But no improvements.
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020

Copy link


Copy Markdown

Try https://unpkg.com/pdfkit-next@0.10.0/js/pdfkit.standalone.js
Thank you. Just tried it and no improvements.
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
What font are you using?

What text do you get an error?
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
This repl it shows correct output with pdfkit-next: https://repl.it/@blikblum/pdfkit-notosans
When using published pdfkit package, there are errors
@blikblumblikblum
mentioned this pull request
Feb 20, 2020
 Closed

@ghislain-sc
ghislain-sc
commented
May 8, 2020

Copy link


Copy Markdown

Hi, sorry for the long delay.
To answer your question: I was using Noto Sans SC. I tried all font weights, tried unhinted, hinted, tried converting it to TTF, use OTF. Also tried Adobe Source Han Sans (which is the exact same font) available in OTF and TTF...
The problem always appears when the text include punctuation, wether Chinese or English. The problem might occur before the punctuation or after. When rendering a paragraph without punctuation, there is no problem. Example of punctuation creating problems: ()" ' , ; : 。，：“ ‘ （）「」...
After several attempts I had settled for a half solution, back in January: I used Noto for all Chinese characters and switched to PingFang for Chinese punctuation. In order to do so, I checked each character with .match(/[\x20-\x7E]/) and .match(/[\u3400-\u9FBF]/).
This solution was less than ideal, it meant a lot of processing for every single paragraph. Even the font switch wasn't that noticeable since I used Pingfang only for special characters, it was still disturbing enough. Finally the PDFs generated were fine in the browser and most preview apps, but appeared broken when open with Adobe Acrobat. So we just stopped.
In the end we just gave up the idea of generating PDFs from our website. But today I noticed the comments and so I gave a look at the repl it. Actually the problem still shows with the Noto font PDF. As you can see the second line should read "产品名:", but it shows only "产 :"
The mistake appears far enough to be too noticeable, which is probably why you thought it was fixed. Then I ran the repl it with a complete paragraph, including more special characters. And the problem is still definitely here.
We don't have immediate use for this anymore, but I believe other people might. I'll try to check this thread more often, let me know if you need more details. Thank you.
@ghislain-sc
ghislain-sc
commented
May 18, 2020

Copy link


Copy Markdown

Hi, for anyone looking to use this specific font Noto Sans SC / TC with PDF Kit, there is actually a workaround. Google's Noto Sans SC and Adobe's Source Han SC are actually the same font, made by the same designer. And there is a TTF version of Adobe's version here: https://github.com/Pal3love/Source-Han-TrueType
Once using this file, everything works well.
@t6adevt6adev
mentioned this pull request
Dec 19, 2020

Closed

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@devongovettdevongovettdevongovett approved these changes

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

4 participants

@blikblum@Harbs@ghislain-sc@devongovett

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Fix getting the fd index for OTF/CFF CID fonts by blikblum · Pull Request #207 · foliojs/fontkit · GitHub
Skip to content
Fix getting the fd index for OTF/CFF CID fonts - #207
Merged
devongovett merged 1 commit into
foliojs:masterfrom 
blikblum:fix-cff-cid
Nov 17, 2019
Merged
Fix getting the fd index for OTF/CFF CID fonts#207
devongovett merged 1 commit into
foliojs:masterfrom 
blikblum:fix-cff-cid
Conversation
@blikblum
@blikblumblikblum
commented
Oct 5, 2019

Copy link


Copy Markdown

Member
There's a logic error in the binary search that looks for fd index in CFFFont#fdForGlyph leading to erroneous result when gid is exactly equal to range.first.
To see the bug load a CID font like NotoSansCJKkr-Regular.otf in https://fontkit-demo.now.sh/ and try to draw character ":" (gid 27)
Its possible to optimize the binary search a bit but will let this for later, just get the minimal change to fix the bug

This was referenced Oct 5, 2019

Open


Closed

@blikblumblikblum
mentioned this pull request
Nov 13, 2019

Closed

@devongovett
devongovett
merged commit cebf94e
into
foliojs:masterNov 17, 2019
@Harbs
Harbs
commented
Nov 17, 2019

Copy link


Copy Markdown

I think this fix is functionally equivalent to pull #168.
You can probably either use that fix, or close the PR. FWIW, I think my fix is slightly more efficient (bails slightly earlier).
@blikblum
blikblum
commented
Nov 17, 2019

Copy link


Copy Markdown

MemberAuthor
You can probably either use that fix, or close the PR. FWIW, I think my fix is slightly more efficient (bails slightly earlier).
Yes. I used the minimal change needed approach to fix it. One advantage of this PR is that contain tests but i agree that your fix is (probably) better performance wise.
I suggest you to rebase your PR on top of current master and run the tests to ensure all clear
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020

Copy link


Copy Markdown

I tried implementing this fix into the standalone version of PDF kit, the problem still appears with Noto Sans SC and Chinese punctuation marks.
The glyphs.js doesn't seem to be included in the standalone version, do I need to include it?
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
I tried implementing this fix into the standalone version of PDF kit, the problem still appears with Noto Sans SC and Chinese punctuation marks.
Can you try https://www.npmjs.com/package/pdfkit-next ? It comes with this fix
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020•

edited

Loading

Copy link


Copy Markdown

I looked into that earlier today, but I wasn't able to compile the next package into a standalone version. (I tried locally on Mac).
I'll try again.
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
Try https://unpkg.com/pdfkit-next@0.10.0/js/pdfkit.standalone.js
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020

Copy link


Copy Markdown

I just tried, using the mac terminal to install "pdfkit-next", then uploading the "pdfkit.standalone.js" located in the "pdfkit-next" folder. But no improvements.
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020

Copy link


Copy Markdown

Try https://unpkg.com/pdfkit-next@0.10.0/js/pdfkit.standalone.js
Thank you. Just tried it and no improvements.
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
What font are you using?

What text do you get an error?
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
This repl it shows correct output with pdfkit-next: https://repl.it/@blikblum/pdfkit-notosans
When using published pdfkit package, there are errors
@blikblumblikblum
mentioned this pull request
Feb 20, 2020
 Closed

@ghislain-sc
ghislain-sc
commented
May 8, 2020

Copy link


Copy Markdown

Hi, sorry for the long delay.
To answer your question: I was using Noto Sans SC. I tried all font weights, tried unhinted, hinted, tried converting it to TTF, use OTF. Also tried Adobe Source Han Sans (which is the exact same font) available in OTF and TTF...
The problem always appears when the text include punctuation, wether Chinese or English. The problem might occur before the punctuation or after. When rendering a paragraph without punctuation, there is no problem. Example of punctuation creating problems: ()" ' , ; : 。，：“ ‘ （）「」...
After several attempts I had settled for a half solution, back in January: I used Noto for all Chinese characters and switched to PingFang for Chinese punctuation. In order to do so, I checked each character with .match(/[\x20-\x7E]/) and .match(/[\u3400-\u9FBF]/).
This solution was less than ideal, it meant a lot of processing for every single paragraph. Even the font switch wasn't that noticeable since I used Pingfang only for special characters, it was still disturbing enough. Finally the PDFs generated were fine in the browser and most preview apps, but appeared broken when open with Adobe Acrobat. So we just stopped.
In the end we just gave up the idea of generating PDFs from our website. But today I noticed the comments and so I gave a look at the repl it. Actually the problem still shows with the Noto font PDF. As you can see the second line should read "产品名:", but it shows only "产 :"
The mistake appears far enough to be too noticeable, which is probably why you thought it was fixed. Then I ran the repl it with a complete paragraph, including more special characters. And the problem is still definitely here.
We don't have immediate use for this anymore, but I believe other people might. I'll try to check this thread more often, let me know if you need more details. Thank you.
@ghislain-sc
ghislain-sc
commented
May 18, 2020

Copy link


Copy Markdown

Hi, for anyone looking to use this specific font Noto Sans SC / TC with PDF Kit, there is actually a workaround. Google's Noto Sans SC and Adobe's Source Han SC are actually the same font, made by the same designer. And there is a TTF version of Adobe's version here: https://github.com/Pal3love/Source-Han-TrueType
Once using this file, everything works well.
@t6adevt6adev
mentioned this pull request
Dec 19, 2020

Closed

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@devongovettdevongovettdevongovett approved these changes

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

4 participants

@blikblum@Harbs@ghislain-sc@devongovett

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Fix getting the fd index for OTF/CFF CID fonts by blikblum · Pull Request #207 · foliojs/fontkit · GitHub
Skip to content
Fix getting the fd index for OTF/CFF CID fonts - #207
Merged
devongovett merged 1 commit into
foliojs:masterfrom 
blikblum:fix-cff-cid
Nov 17, 2019
Merged
Fix getting the fd index for OTF/CFF CID fonts#207
devongovett merged 1 commit into
foliojs:masterfrom 
blikblum:fix-cff-cid
Conversation
@blikblum
@blikblumblikblum
commented
Oct 5, 2019

Copy link


Copy Markdown

Member
There's a logic error in the binary search that looks for fd index in CFFFont#fdForGlyph leading to erroneous result when gid is exactly equal to range.first.
To see the bug load a CID font like NotoSansCJKkr-Regular.otf in https://fontkit-demo.now.sh/ and try to draw character ":" (gid 27)
Its possible to optimize the binary search a bit but will let this for later, just get the minimal change to fix the bug

This was referenced Oct 5, 2019

Open


Closed

@blikblumblikblum
mentioned this pull request
Nov 13, 2019

Closed

@devongovett
devongovett
merged commit cebf94e
into
foliojs:masterNov 17, 2019
@Harbs
Harbs
commented
Nov 17, 2019

Copy link


Copy Markdown

I think this fix is functionally equivalent to pull #168.
You can probably either use that fix, or close the PR. FWIW, I think my fix is slightly more efficient (bails slightly earlier).
@blikblum
blikblum
commented
Nov 17, 2019

Copy link


Copy Markdown

MemberAuthor
You can probably either use that fix, or close the PR. FWIW, I think my fix is slightly more efficient (bails slightly earlier).
Yes. I used the minimal change needed approach to fix it. One advantage of this PR is that contain tests but i agree that your fix is (probably) better performance wise.
I suggest you to rebase your PR on top of current master and run the tests to ensure all clear
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020

Copy link


Copy Markdown

I tried implementing this fix into the standalone version of PDF kit, the problem still appears with Noto Sans SC and Chinese punctuation marks.
The glyphs.js doesn't seem to be included in the standalone version, do I need to include it?
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
I tried implementing this fix into the standalone version of PDF kit, the problem still appears with Noto Sans SC and Chinese punctuation marks.
Can you try https://www.npmjs.com/package/pdfkit-next ? It comes with this fix
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020•

edited

Loading

Copy link


Copy Markdown

I looked into that earlier today, but I wasn't able to compile the next package into a standalone version. (I tried locally on Mac).
I'll try again.
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
Try https://unpkg.com/pdfkit-next@0.10.0/js/pdfkit.standalone.js
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020

Copy link


Copy Markdown

I just tried, using the mac terminal to install "pdfkit-next", then uploading the "pdfkit.standalone.js" located in the "pdfkit-next" folder. But no improvements.
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020

Copy link


Copy Markdown

Try https://unpkg.com/pdfkit-next@0.10.0/js/pdfkit.standalone.js
Thank you. Just tried it and no improvements.
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
What font are you using?

What text do you get an error?
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
This repl it shows correct output with pdfkit-next: https://repl.it/@blikblum/pdfkit-notosans
When using published pdfkit package, there are errors
@blikblumblikblum
mentioned this pull request
Feb 20, 2020
 Closed

@ghislain-sc
ghislain-sc
commented
May 8, 2020

Copy link


Copy Markdown

Hi, sorry for the long delay.
To answer your question: I was using Noto Sans SC. I tried all font weights, tried unhinted, hinted, tried converting it to TTF, use OTF. Also tried Adobe Source Han Sans (which is the exact same font) available in OTF and TTF...
The problem always appears when the text include punctuation, wether Chinese or English. The problem might occur before the punctuation or after. When rendering a paragraph without punctuation, there is no problem. Example of punctuation creating problems: ()" ' , ; : 。，：“ ‘ （）「」...
After several attempts I had settled for a half solution, back in January: I used Noto for all Chinese characters and switched to PingFang for Chinese punctuation. In order to do so, I checked each character with .match(/[\x20-\x7E]/) and .match(/[\u3400-\u9FBF]/).
This solution was less than ideal, it meant a lot of processing for every single paragraph. Even the font switch wasn't that noticeable since I used Pingfang only for special characters, it was still disturbing enough. Finally the PDFs generated were fine in the browser and most preview apps, but appeared broken when open with Adobe Acrobat. So we just stopped.
In the end we just gave up the idea of generating PDFs from our website. But today I noticed the comments and so I gave a look at the repl it. Actually the problem still shows with the Noto font PDF. As you can see the second line should read "产品名:", but it shows only "产 :"
The mistake appears far enough to be too noticeable, which is probably why you thought it was fixed. Then I ran the repl it with a complete paragraph, including more special characters. And the problem is still definitely here.
We don't have immediate use for this anymore, but I believe other people might. I'll try to check this thread more often, let me know if you need more details. Thank you.
@ghislain-sc
ghislain-sc
commented
May 18, 2020

Copy link


Copy Markdown

Hi, for anyone looking to use this specific font Noto Sans SC / TC with PDF Kit, there is actually a workaround. Google's Noto Sans SC and Adobe's Source Han SC are actually the same font, made by the same designer. And there is a TTF version of Adobe's version here: https://github.com/Pal3love/Source-Han-TrueType
Once using this file, everything works well.
@t6adevt6adev
mentioned this pull request
Dec 19, 2020

Closed

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@devongovettdevongovettdevongovett approved these changes

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

4 participants

@blikblum@Harbs@ghislain-sc@devongovett

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Universal Dark Mode - works on any site
(function() {
var enabled = true;
function applyDarkMode() {
if (!enabled) return;
// Create style element if it doesn't exist
var style = document.getElementById('universal-dark-mode-style');
if (!style) {
style = document.createElement('style');
style.id = 'universal-dark-mode-style';
document.head.appendChild(style);
}
// Dark mode CSS - inverts colors but preserves images/video
style.textContent = '
/* Invert everything except media */
html {
filter: invert(1) hue-rotate(180deg) !important;
background: #1a1a2e !important;
}
/* Restore images, videos, iframes, canvas */
img, video, iframe, canvas, svg, picture, [style*="background-image"] {
filter: invert(1) hue-rotate(180deg) !important;
}
/* Preserve specific elements that should not be inverted */
.no-dark-mode, .no-dark-mode *,
[data-theme="light"], [data-theme="light"],
.ace_editor, .ace_editor *,
.CodeMirror, .CodeMirror *,
.monaco-editor, .monaco-editor *,
.markdown-body pre, .markdown-body pre *,
.highlight, .highlight *,
pre code, pre code * {
filter: none !important;
}
/* Fix common UI elements */
.modal, .popup, .dropdown-menu, .tooltip, .popover {
filter: invert(1) hue-rotate(180deg) !important;
background: #2d2d44 !important;
border-color: #444 !important;
}
/* Scrollbars */
::-webkit-scrollbar { background: #1a1a2e !important; }
::-webkit-scrollbar-thumb { background: #444 !important; }
::-webkit-scrollbar-thumb:hover { background: #555 !important; }
/* Selection */
::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
';
}
function removeDarkMode() {
var style = document.getElementById('universal-dark-mode-style');
if (style) style.remove();
}
// Toggle with Alt+Shift+D
document.addEventListener('keydown', function(e) {
if (e.altKey && e.shiftKey && e.key === 'D') {
e.preventDefault();
enabled = !enabled;
if (enabled) {
applyDarkMode();
console.log('[Universal Dark Mode] Enabled');
} else {
removeDarkMode();
console.log('[Universal Dark Mode] Disabled');
}
}
});
// Apply on load
applyDarkMode();
// Re-apply on dynamic content
var observer = new MutationObserver(function(mutations) {
if (enabled && !document.getElementById('universal-dark-mode-style')) {
applyDarkMode();
}
});
observer.observe(document.head, { childList: true });
console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');
})();
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();
Fix getting the fd index for OTF/CFF CID fonts by blikblum · Pull Request #207 · foliojs/fontkit · GitHub
Skip to content
Fix getting the fd index for OTF/CFF CID fonts - #207
Merged
devongovett merged 1 commit into
foliojs:masterfrom 
blikblum:fix-cff-cid
Nov 17, 2019
Merged
Fix getting the fd index for OTF/CFF CID fonts#207
devongovett merged 1 commit into
foliojs:masterfrom 
blikblum:fix-cff-cid
Conversation
@blikblum
@blikblumblikblum
commented
Oct 5, 2019

Copy link


Copy Markdown

Member
There's a logic error in the binary search that looks for fd index in CFFFont#fdForGlyph leading to erroneous result when gid is exactly equal to range.first.
To see the bug load a CID font like NotoSansCJKkr-Regular.otf in https://fontkit-demo.now.sh/ and try to draw character ":" (gid 27)
Its possible to optimize the binary search a bit but will let this for later, just get the minimal change to fix the bug

This was referenced Oct 5, 2019

Open


Closed

@blikblumblikblum
mentioned this pull request
Nov 13, 2019

Closed

@devongovett
devongovett
merged commit cebf94e
into
foliojs:masterNov 17, 2019
@Harbs
Harbs
commented
Nov 17, 2019

Copy link


Copy Markdown

I think this fix is functionally equivalent to pull #168.
You can probably either use that fix, or close the PR. FWIW, I think my fix is slightly more efficient (bails slightly earlier).
@blikblum
blikblum
commented
Nov 17, 2019

Copy link


Copy Markdown

MemberAuthor
You can probably either use that fix, or close the PR. FWIW, I think my fix is slightly more efficient (bails slightly earlier).
Yes. I used the minimal change needed approach to fix it. One advantage of this PR is that contain tests but i agree that your fix is (probably) better performance wise.
I suggest you to rebase your PR on top of current master and run the tests to ensure all clear
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020

Copy link


Copy Markdown

I tried implementing this fix into the standalone version of PDF kit, the problem still appears with Noto Sans SC and Chinese punctuation marks.
The glyphs.js doesn't seem to be included in the standalone version, do I need to include it?
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
I tried implementing this fix into the standalone version of PDF kit, the problem still appears with Noto Sans SC and Chinese punctuation marks.
Can you try https://www.npmjs.com/package/pdfkit-next ? It comes with this fix
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020•

edited

Loading

Copy link


Copy Markdown

I looked into that earlier today, but I wasn't able to compile the next package into a standalone version. (I tried locally on Mac).
I'll try again.
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
Try https://unpkg.com/pdfkit-next@0.10.0/js/pdfkit.standalone.js
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020

Copy link


Copy Markdown

I just tried, using the mac terminal to install "pdfkit-next", then uploading the "pdfkit.standalone.js" located in the "pdfkit-next" folder. But no improvements.
@ghislain-sc
ghislain-sc
commented
Jan 14, 2020

Copy link


Copy Markdown

Try https://unpkg.com/pdfkit-next@0.10.0/js/pdfkit.standalone.js
Thank you. Just tried it and no improvements.
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
What font are you using?

What text do you get an error?
@blikblum
blikblum
commented
Jan 14, 2020

Copy link


Copy Markdown

MemberAuthor
This repl it shows correct output with pdfkit-next: https://repl.it/@blikblum/pdfkit-notosans
When using published pdfkit package, there are errors
@blikblumblikblum
mentioned this pull request
Feb 20, 2020
 Closed

@ghislain-sc
ghislain-sc
commented
May 8, 2020

Copy link


Copy Markdown

Hi, sorry for the long delay.
To answer your question: I was using Noto Sans SC. I tried all font weights, tried unhinted, hinted, tried converting it to TTF, use OTF. Also tried Adobe Source Han Sans (which is the exact same font) available in OTF and TTF...
The problem always appears when the text include punctuation, wether Chinese or English. The problem might occur before the punctuation or after. When rendering a paragraph without punctuation, there is no problem. Example of punctuation creating problems: ()" ' , ; : 。，：“ ‘ （）「」...
After several attempts I had settled for a half solution, back in January: I used Noto for all Chinese characters and switched to PingFang for Chinese punctuation. In order to do so, I checked each character with .match(/[\x20-\x7E]/) and .match(/[\u3400-\u9FBF]/).
This solution was less than ideal, it meant a lot of processing for every single paragraph. Even the font switch wasn't that noticeable since I used Pingfang only for special characters, it was still disturbing enough. Finally the PDFs generated were fine in the browser and most preview apps, but appeared broken when open with Adobe Acrobat. So we just stopped.
In the end we just gave up the idea of generating PDFs from our website. But today I noticed the comments and so I gave a look at the repl it. Actually the problem still shows with the Noto font PDF. As you can see the second line should read "产品名:", but it shows only "产 :"
The mistake appears far enough to be too noticeable, which is probably why you thought it was fixed. Then I ran the repl it with a complete paragraph, including more special characters. And the problem is still definitely here.
We don't have immediate use for this anymore, but I believe other people might. I'll try to check this thread more often, let me know if you need more details. Thank you.
@ghislain-sc
ghislain-sc
commented
May 18, 2020

Copy link


Copy Markdown

Hi, for anyone looking to use this specific font Noto Sans SC / TC with PDF Kit, there is actually a workaround. Google's Noto Sans SC and Adobe's Source Han SC are actually the same font, made by the same designer. And there is a TTF version of Adobe's version here: https://github.com/Pal3love/Source-Han-TrueType
Once using this file, everything works well.
@t6adevt6adev
mentioned this pull request
Dec 19, 2020

Closed

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@devongovettdevongovettdevongovett approved these changes

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

4 participants

@blikblum@Harbs@ghislain-sc@devongovett