-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Conversation
Conflicts: src/HTMLRenderer/general.cc src/HTMLRenderer/state.cc
@@ -125,6 +125,22 @@ span { | |||
} | |||
.a { | |||
} | |||
/* transparent color - Firefox, IE, etc. */ | |||
.ct { /*fill*/ | |||
color: white; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not color:transparent
we cannot assume that the background is white.
And yeah, we are running out of letters for the classes, I'll have to rearrange them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't work because the shadow occupies the entire area behind the text and not just the area around the edges. So you end up just seing the shadow color filling the entire text, which is equivalent to filling the text with the stroke color. Presuming the background is white is the best we can do, it's going to work 80% of the time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right..hmm let me think about it
Good job! Please check my comments. You just trigger my "better, moreflexible class style names and state tracing, when there are too many styles" job. And do you have any test cases for this? I don't have one. |
I linked to a PDF file in my original pull request message. |
Thanks! I'll revise and write the state classes. Do you now think the 2nd approach (sequential chars) is better? |
Checking the code, why do you use two layers. It should work if you set |
That's just how the PDF was made, I didn't make it. Works fine in WebKit. |
So I guess it's the white-as-transparent issue. On Sat, Feb 2, 2013 at 11:40 PM, John Hewson notifications@github.comwrote:
|
No, color:trasparent does not fix this. Let me think about it.. On Sat, Feb 2, 2013 at 11:42 PM, 王璐 coolwanglu@gmail.com wrote:
|
Yes, the layering is just a quirk of this particular PDF file. The stroke + fill render mode (mode 2) should work fine in Firefox - I just don't have a PDF to hand which uses that mode. |
Try this PDF file which uses text rendering mode 2 (fill + stroke) http://libharu.sourceforge.net/demo/text_demo.pdf It works fine in Firefox. |
OK. I'll mark it as On Sat, Feb 2, 2013 at 11:51 PM, John Hewson notifications@github.comwrote:
|
There isn't a solution as far as I can tell until |
Actually render them into the background image is a solution... with a On Sat, Feb 2, 2013 at 11:56 PM, John Hewson notifications@github.comwrote:
|
Yuck. |
I just broke the text stroke simulation in Firefox, in order to "show" hidden text in HTML (render==3). |
@jahewson @coolwanglu this is a long shot but I'm hitting an issue which I THINK is related to this PR. On Chrome (or it seems other webkit browsers) I'm seeing a stroke on text that SHOULD be invisible. I'm trying to figure out what this PR was originally trying to solve? I'm trying to nail down why a particular document is getting this stroke applied by pdf2htmlEX & how I might solve the issue on my side. |
I've implemented stroked text, and split the text color into two separate colors for fill and stroke. This works perfectly in WebKit via
-webkit-text-stroke
and is emulated in other browsers usingtext-shadow
.text-shadow
fallback does not supportcolor: transparent
for fills, because the shadow occupies the entire area behind the text and so a transparentcolor
results in seeing the entire shadow. I've usedcolor: white
as the "no-fill" fallback, so that at least when the background is white it works correctly.GfxState
, because thetext-shadow
fallback forces both color and width to be defined at the same time, which doesn't fit well with the existing color+hash mechanism used in the "install" procedures. I've used a sensible default based on the em size.Here's some sample output and the sample PDF, note that the yellow filled text does not appear filled in Firefox because it is not using the stroke + fill rendering mode, it is actually two pieces of text layered on top of each other.