I am trying to save a pdf from illustrator and I have never had this issue, the font looks fine in illustrator, but when I save the pdf and open the pdf in a pdf viewer the "i" character now has a box beneath the text but the dot of the i stays there.
When viewed in illustrator:
When viewed in a PDF viewer:
I know that when the square shows up it means the font you are trying to use isn't there however the other characters appear fine, it just seems to be the I which is odd. The font passed verification (for reference it is Playfair Display
Does anyone know how to fix this or why this could be occurring? Am I exporting wrong(I've never had this issue before with exporting)?
Thanks in advance!
Update: I solved my question while writing it. The font that was installed was a variable font type (I downloaded it from Google), for some reason it doesn't seem to want to play nicely in a pdf (maybe I'm saving it incorrectly?). I deleted the variable font and installed the static versions of the font and now the issue has gone away.
I don't know too much about variable fonts but it seems like they are maybe a bit finicky?
Hope this can help others!
It somehow seems that the width of the symbol's "collision" is almost 0, but it is rendered as normal.
What causes this and is it possible to fix it? I tried searching everywhere but I can't find anything on this bug/feature.
Example Files of this (.odt and .pdf)
I'm still new to coding. I downloaded flex slider, and I have it running fine on my site and working fine. However I can't make ANY edits into my html regarding the slider. It has the 'next' and 'previous' image links on my gallery, which I would like to replace. It shows up in the html when I inspect it in firebug, yet when I run my html through my text editor (Im using text mate), it doesn't show up at all!
Any ideas why?
I think you are talking about the navigational arrows on the left and right side of the images. This can be changes in the "flexslider.css" file. If you are using textmate then the line number is 52.
Probably the easiest way is to find the image here images/bg_direction_nav.png. Right click the image and open with your image editing software eg. photoshop. Then once you have change the image just save it and it will be saved in the same folder location. If you keep the image the same size then you will not have to mess around with anything else..
SEO issue red characters
Hi all
I'm building webstes using dreamweaver, but when I look at the source code it is red for " characters. I'm told anything appearing in red puts off Google's seo. Does anyone know why this appears in red?
For example when I view code source on the site i get the gt; in red
Find out more>></span>
</div>
Thanks for your help
Regards
Judi
I'm told anything appearing in red puts off googles seo.
That is garbage.
Does anyone know why this appears in red?
Probably because it is an entity and has been marked by the syntax highlighter so you can spot in amongst literals.
Google SEO aside, it's important to understand that there's a world of difference between using CSS to control the colour of text, and the syntax highlighting done by the DreamWeaver editor.
Colours seen when you are viewing the HTML source of your page in a tool like Dreamweaver have nothing to do with the colours seen when viewing your page in a browser.
All that's happening is that Dreamweaver is syntax colouring HTML escape characters in red, I am pretty sure that you have nothing to worry about.
Edit
You clarified that in fact you're not viewing the HTML source in Dreamweaver.
Are you viewing source from Firefox?
Firefox syntax colours HTML in its "source of" viewer. HTML escape codes are shown in red (Firefox 3.6, Windows). The point still stands however that this is just syntax colouring and has nothing to do with how your page gets rendered by the browser, or anything to go with Google SEO.
This might be a bit off topic and of course no-brainer for you guys, but anyway:
Firefox highlights all open lines as red. If you have for example:
meta content="text...
and there is no /> at the end of the line, then Firefox makes that line appear red when you use "view page source".
Though that's not the reason for red highlight in your case.
I can view source in Firefox 11 (Win) and see bolded and non-bolded red highlighted markup. If I hover over the bolded red markup, I see a pop-up description of the problem Firefox is finding with the HTML source. For example:
Start tag seen without seeing a doctype first. Expected "<!DOCTYPE html>"
Start tag "div" seen in "table"
Stray end tag "table"
Stray end tag "div"
In non-bolded red highlighted syntax I see entities such as:
, &, >
Firefox 11 allows you to configure and use an external application to View Source. It also has several configuration values in about:config ("view_source.syntax.highlight" for example) that control how the feature is delivered.
The bolded red source highlighting in Firefox View Source may or may not cause issues with SEO. It's an indication that the browser is finding an issue with the HTML markup in the page you're viewing.
The issue of how much invalid HTML harms you with respect to SEO is debated. (And as pointed out in a separate answer, also depends on where the invalid markup appears.) This youtube video discusses HTML validation and Google SEO: http://www.youtube.com/watch?v=2XlKn6I9rSc.
I'm told anything appearing in red puts off googles seo
No. Just no. Google's SEO works on a text-basis, it ignores any colouring or formatting within a page.
The colour of the text in the source code is simply based on DreamWeaver's syntax highlighting - if you run and view your page in a browser, it shouldn't be this colour (assuming you aren't actually setting the colour of this to red).
Google will check for color on same color text and background to make sure hidden keywords aren't being used on the page. To google, white on white text is a no-no.
In Dreamweaver, syntax highlight of HTML entities does not translate into a bad 'mark' in the SEO book.
Now on the other hand, if you have key phrases in your link text that includes (>)'s, then your SEO work for the key phrase is shot because the >'s are counted as part of the key phrase.
You can probably turn red highlighting of entities off in Dreamweaver's preferences....
I created a simple report and uploaded it to my report server. It looks correct on the report server, but when I set up an email subscription, the report is much narrower than it is supposed to be.
Here is what the report looks like in the designer. It looks similar when I view it on the report server: [http://img58.imageshack.us/img58/4893/designqj3.png]
Here is what the email looks like: [http://img58.imageshack.us/img58/9297/emailmy8.png]
Does anyone know why this is happening?
This issue is fixed in SQL Server 2005 SP3 (it is part of cumulitive update package build 3161)
Problem issue described below.
http://support.microsoft.com/kb/935399
Basically Full Outlook 2007 Client Uses MS Word HTML Rendering Engine (Which Makes Web Archive Report Looked Jacked Up).
NOTE: Web Outlook 2007 Client Uses IE HTML Rendering Engine (Which makes Web Archive Report Look Okay).
We have installed the patch on DB housing Reporting Services and it does fix the issue. Emails look all nice and fancy now.
I notice that the screenshots show Outlook 2007. Perhaps you're not aware that Microsoft somewhat hobbled the HTML capabilities of Outlook in 2007, and now it uses the Word HTML engine, and not the more advanced Internet Explorer one? Might this explain the lacklustre appearance?
http://www.sitepoint.com/blogs/2007/01/10/microsoft-breaks-html-email-rendering-in-outlook/
I got around this problem by doing the
following:
Add a Page Header to the report
Add a line to the page header. Set the width of the line to the
desired page width.
Set the line colour to white (eg to hide the line)
Hope this helps someone else,
Following on from girlC0d3r's solution, images aren't always guaranteed to be shown in an email.
A better solution to widening the report to prevent the content from wrapping is to have a long unbroken string of characters with no whitespace.
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
By giving the text the same color as the background of the email (e.g. white) they'll widen the report and be invisible to the user.
I don't see anything but my first guess is that the fonts are vastly different. The designer has one font and the email is a flat, no-frills kind of thing with a simple font. Without concrete examples, this is just a guess.
I don't think it's a font thing, because the text is being wrapped a lot, and it looks about the same size.
The images show in my preview, but not in the final post. So, here are links to them.
Report in the designer: [http://img58.imageshack.us/img58/4893/designqj3.png]
Email result: [http://img58.imageshack.us/img58/9297/emailmy8.png]
What report output format did you specify for the scheduled job? It seems to me you used HTML, which will autoscale depending on the output browser (HTML adapts).
If having the same layout is important then use PDF as the output format. Then, if the user wants to print the report you know exactly what it will look like and that it will fit nicely on the page.
Can you try a different format? pdf or xls maybe. In my experience web archive looks goofy. Don't know why.
Yeah, I'm using HTML. I would prefer to stick with that, because the users can just read it in their mail clients. PDF or XLS would require them to open an attachment.
I know that the HTML resizes itself to fit the browser, and that's a good thing. The problem I would like to fix is the wasted space - in the email client, the HTML shrinks too much.
I got around this problem by doing the following:
Add a Page Header to the report
Add a line to the page header. Set the width of the line to the desired page width.
Set the line colour to white (eg to hide the line)
Hope this helps someone else,
girlC0d3r is along the right lines (no pun intended), but the line will likely be shrunk along with the rest of the HTML in the email. A workaround I used yesterday was to create an image 1px high by 600px wide (or whatever), the same color as the background, and bring it into the report as an embedded image. Place it above or below the body of your report. This should force the intended width in the final email. I used this technique successfully in a report yesterday.
I just ran into this issue myself, exactly as portrayed in the OP's screenshots. The reports were beautifully rendered in nearly every format except for Web Archive. My trouble was the use of a rectangle containing each matrix that did not span the width of the report. Upon stretching it out through the remaining white space, the condensing behavior ceased. Hope that helps someone who doesn't have quick access to an SP upgrade!
Where it is not an issue of running on old software that needs a patch...
The reason is the columns are different sizes is because the MHTML Device Information Settings, 'OutlookCompat' is set to true
When creating an email subscription with MHTML format and open the report in Outlook, A forum post by Microsoft employee Fanny Liu says
change the OutlookCompat configuration setting for the MHTML Rendering extension in rsreportserver.config. Set the value to: False.
As I was researching it appeared that this would impact more than just column size. In my instance it was not that big of deal so I decided to leave well enough alone. It is correct in PDF and web, the email I send includes a link back to the report, if the client wants a pretty report they are going to want it in PDF, the email format is not expected to be printable.
Encountered the same issue and this worked for me.
Go to --> Properties --> Report
Set InteractiveSize Width to 4.9in
Set Margins to 0 for Left, Right, Top, and Bottom
Set pageSize to Width to 4.9in