broncopie

> “you have to change path of every link”

How do I do this?
Thanks.

Thank you.
Manual updating according to those steps, appears to have solved it.

Thank you.
I use Canvas theme (from Woo), and many plugins. (including RICG Responsive Images, Responsive Lightbox)

How does one go about finding out which plugin is creating the 20+ different reduced-size versions of every large original image? (Preferably something better than deactivating each suspected plugin and re-trying)

I understand scaling down an image necessarily loses image detail, but for a ( PNG-original -> scale-down -> PNG ) process, we should not end up with pale grey artifacts in large open swaths of what’s supposed to be pure white. My images appear to be made by ( PNG-original -> scale-down -> JPEG -> PNG ). I understand that this wasn’t EWWW Image Optimizer.

• This reply was modified 8 years ago by broncopie.

Thank you.
I have installed EWWW Image Optimizer, and the Bulk Optimize job is running now.
I see that the compression artifacts in the small-versions are still present after EWWW optimization. I need to try to get EWWW to regenerate the small versions from scratch.

I have found the cause:
Chrome at 110% (or higher) zoom gets served the resized version.
Chrome at 100% (or lower) zoom gets the original version.

Not sure where to check for png lossy-resize bugs though.

Thanks!

Is there a way to troubleshoot what a browser might be reporting that causes it to be served a resized image, while an similar other set of browser-OS-hardware is being served the original image?

Thank you James Huff.

I have two different Win10 dekstops, both displays are set at 1920 x 1080, both using Chrome.
One gets served the original, while the other only gets the -1200×1408.png versions.
I don’t know what is causing the difference.

Before I use that plugin… I just like to ask, can joe-visitor do anything to retrieve the original image, or even discover that a higher quality original is available?

I would also like to bug-report the resizing of PNG’s has jpeg-like artifacts. Reproduce this bug with a PNG containing simple black line diagrams / text on white background, and you will see that the small versions have their white backgrounds filled with light grey horizontal stripe compression artifacts.

Thank you!

The CSS lines are in the generated (index) page file itself, they look like this:

.widget h3 {font:bold 14px/1.2em Arial, sans-serif;color:#555555;border-bottom:1px solid #e6e6e6;}
.widget_recent_comments li, #twitter li { border-color: #e6e6e6;}
.widget p, .widget .textwidget { font:300 13px/1.5em Arial, sans-serif;color:#555555; }
.widget {font:300 13px/1.5em Arial, sans-serif;color:#555555;border-radius:0px;-moz-border-radius:0px;-webkit-border-radius:0px;}

And the affected HTML looks like this:

<h3 class=”widget-title”>a title for text widget</h3>
<div class=”textwidget”>content for text widget</div>

These appear only if the “Text” or the “Visual Editor” widgets are used within “Page Builder” by SiteOrigin.

Should I be trying to override them in custom.css?
Or is there a “correct” place to set them?

When using Chrome’s Inspect Element, the relevant CSS is shown to be in (index):125 ?

It appears that (index) refers to the main generated HTML+CSS page itself. i.e. it means that the relevant CSS lines do not exist in separate CSS files.
My question is how did those lines get into the main page file?

screenshot:
https://i.imgur.com/z1V5LtH.png

Does “textwidget” correspond to a certain plugin?