reporter@ - Thanks for filing the issue...!!

Could you please provide a sample test file/url to test the issue from TE-end. This will help us in triaging the issue further.

Thanks...!!

Sure thing. I've attached the .pdf that we are opening in Chrome. I believe it is "Styling master document from stylesheets defined in HTML Imports is deprecated." according to the console when inspecting. I'm rebuilding the entire file from scratch as we needed to update it anyway and making it more "universally friendly" as well. The Font should match the font of the other text except that it is maroon instead of gold. 

Deleted: Online School Certificate.pdf 3.5 MB

Online School Certificate.pdf 3.5 MB Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

My guess is that the font is not embedded in the PDF and we don't find it when loading fonts initially, so we fallback to the default font as a substitution. If that's the case, the question would be why can't we find the needed font on your system.

Using non-embedded fonts with PDF files can often lead to using substitute fonts.

PDFFonts says that there is one font and it is embedded... so maybe there is a problem with the way you're specifying the font in the textfields? Or we could have a bug in our form reading code.

Can you confirm that this worked on a previous version of Chrome, and which? I see your answer was "Yes 67.0.3396.85" but the Chrome version of when it worked seems suspicious.

I'm rebuilding the file and embedding the fonts to see if that works. If it does I will test again and let you know. We've been doing this for 3 years in Chrome. It worked until last week. I'm assuming it worked with the most current previous version as this process we do happens on almost a daily basis and Chrome updates automatically. We did not have any issues until last week.

Ok thanks! In this case we do need a bisect and the range is probably M66 - M67. 	krajshree@ are you able to bisect this on Windows and assign to the offending CL?

Finished rebuilding the file. Made sure the fonts are embedded. Still the same issue when opening in Chrome. I added some text so you can see the field. Opening in Adobe Reader even on an iPad can find the embedded fonts. When you open in Chrome, as soon as you edit the text, it loses connection to the font. Attached is the newest file.

Deleted: 2018-Certificate.pdf 1.3 MB

2018-Certificate.pdf 1.3 MB Download

Able to reproduce the issue on Windows 10, mac 10.13.3 and Ubuntu 17.10 using chrome reported version #67.0.3396.87 and latest canary #69.0.3465.0.

Bisect Information:
=====================
Good build: 67.0.3382.0
Bad Build : 67.0.3383.0

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/b0770c15dc9aa7020829bb421fb88e4dc2ff7347..8b119117f67d88b5fcd1ed9195f94875245fa95a

pdfium-chromium-autoroll Change log URL:
https://pdfium.googlesource.com/pdfium.git/+log/8eac5ad73918..cbf76e656042

From the above change log suspecting below change
Change-Id: I1dc64e54aedd03d059b963121d466f3eb75c17db
Reviewed-on: https://pdfium-review.googlesource.com/28410

dsinclair@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.
Note: Adding stable blocker for M-67 as it seems to be a recent regression. Please feel free to remove the same if not appropriate.

Thanks...!!

npm@ would you be able to figure out which of the 8 CLs in that roll are the issue?

M67 stable has been out since 05/29 and we're not planning M67 stable respin unless extremely critical issue arise. Pls target fix for M68. Pls let us know if there is any concern here. Thank you.

No need to target for M67.
I confirmed that the culprit is 53a8093c6ef694ec520fe0b087fbac86af97f5e8

...and that link doesn't work so by that I mean https://pdfium-review.googlesource.com/28410

Removing "Target-67" & "M-67" label per comment #15. Thank you.

CL is in progress but due to lack of tests and because 68 is already in Beta I vote we don't merge and instead let the change bake and arrive in M69. Any others have thoughts on this? For this bug in particular the regression only changes the choice of font so it just doesn't look as pretty.

Also, this is not an iOS bug.

Since it's a regression, why don't we revert the culprit?

Because the CL was written months ago and it wouldn't be a clean revert anyways.

FWIW I think the CL accidentally fixed some cases and broke other cases. We just don't have enough test coverage for this stuff.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/69161a20b63918f63caa0c57cc171bcdbe0983dc

commit 69161a20b63918f63caa0c57cc171bcdbe0983dc
Author: pdfium-chromium-autoroll <pdfium-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Date: Wed Jun 20 22:40:54 2018

Roll src/third_party/pdfium b6b01cb2cbaf..cc4802edc4fa (2 commits)

https://pdfium.googlesource.com/pdfium.git/+log/b6b01cb2cbaf..cc4802edc4fa


git log b6b01cb2cbaf..cc4802edc4fa --date=short --no-merges --format='%ad %ae %s'
2018-06-20 npm@chromium.org Fix a couple of CPDF_DefaultAppearance::GetFont usages
2018-06-20 tsepez@chromium.org Avoid more .c_str() usage, part 3


Created with:
  gclient setdep -r src/third_party/pdfium@cc4802edc4fa

The AutoRoll server is located here: https://pdfium-roll.skia.org

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.



BUG= chromium:853238 
TBR=dsinclair@chromium.org

Change-Id: Ic52e974886de5023884a44852335bf096e1f0ebf
Reviewed-on: https://chromium-review.googlesource.com/1108897
Reviewed-by: pdfium-chromium-autoroll <pdfium-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Commit-Queue: pdfium-chromium-autoroll <pdfium-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#569056}
[modify] https://crrev.com/69161a20b63918f63caa0c57cc171bcdbe0983dc/DEPS

Fixed and no thoughts on whether we should request a merge. Removing RB Stable label since this bug is already in Stable anyways.

Able to reproduce the issue on Mac 10.13.3 using chrome reported version #67.0.3396.87.

Verified the fix on Mac 10.13.3 and Ubuntu 14.04 using chrome version #69.0.3469.0 and verified on win-10 using latest chrome version #69.0.3469.3 as per the comment #0.
Attaching screen cast for reference.
Observed that when filling in the form, the font is the same font that the form was built with.
Hence, the fix is working as expected. 
Adding the verified labels.

Thanks...!!

Deleted: 853238.mp4 1.0 MB

	853238.mp4 1.0 MB View Download

I just wanted to say, thank all of you for looking into this bug. It has been fascinating to watch the exchange between all of you on this post. I appreciate the resolve to find the problem and fix it. This morning I showed our team how you all have a fix that is available in Canary and it has our employees very thankful. You are appreciated for what you do and we look forward to the stable release when this feature is working again! Thank you!