Garbled when renaming css file

sregiter · 06-09-2020, 07:32 PM

Hi, guys.

I encounter the error on encoding when renaming css file, probably indicating a bug in the SIGIL as shows the following:

[IMG]garbled.png[/IMG]

SIGIL
version: 1.2.0
Loaded Qt: 5.1.2.7:
Buld time: 2020.03.28 00.:23:48 UTC

DiapDealer · 06-09-2020, 07:42 PM

Hmmm. It's url encoding that property value for some reason.

Might be something wrong with the regex that finds urls in css when renaming files/updating links.

We'll have to do some investigating. Thanks for the report/sample.

DiapDealer · 06-09-2020, 07:51 PM

Does it change at all if you correct the syntax of your ::before ::after pseudo elements?

DiapDealer · 06-09-2020, 08:13 PM

I can replicate it. The good news is that the url encoding doesn't actually affect the rendering of the generated content at all. But we'll still probably need to track down why it's happening.

sregiter · 06-09-2020, 08:17 PM

I corrected the syntax in the pseudo elements as you said, but the garbling still occurs.

DiapDealer · 06-09-2020, 08:27 PM

The content property is definitely one that gets parsed for urls to update when renaming files. But I can't immediately see why your non-url value is getting detected as an url. The regex is a bit convoluted. I'll have to stare at it for a while. But it's definitely getting detected as an url. That's the only reason the url-encoding would be applied.

It's definitely a bug on our end.

DiapDealer · 06-09-2020, 08:41 PM

I see it, but I definitely don't know what to do about it yet. As it stands, any content property's string value is always going to get url-encoded. But also as noted: rendering of the content is unaffected.

By my estimation... any quoted string value in any of the css properties that CAN contain urls is always going to get url-encoded.

KevinH · 06-09-2020, 09:08 PM

According to some sources, if the content property is a url it should be wrapped in "url()".

See this example from https://www.w3schools.com/cssref/pr_gen_content.asp

Code:

<!DOCTYPE html>
<html>
<head>
<style>
p::before {
  content: url(w3css.gif);
}
</style>
</head>
<body>

<p>My name is Donald</p>
<p>I live in Ducksburg</p>

</body>
</html>

So if the "url()" wrapper is required for a url in a content property we should be able to restrict on that, right?

DiapDealer · 06-09-2020, 09:23 PM

Quote:

Originally Posted by KevinH

So if the "url()" wrapper is required for a url in a content property we should be able to restrict on that, right?

We should, yes. I'll have to figure a way to restrict the content property to only a content property that uses the url key word.

But right now, I'm trying to figure out what on earth I had in mind with the second half of the urls regex in PerformCSSUpdates. Even if it doesn't match on the url keyword, the second half of the "or" will match pretty-much any character(s) between to matched double or single quotes. I looked back through the history and the change is definitely on me (way back with the original multiple urls in the same property fix), but I can't for the life of me figure out what I was TRYING to capture with the:

Code:

"[\"']([^\\(\\)\"']*)[\"']"

portion of that regexp.

KevinH · 06-09-2020, 09:29 PM

Actually, the url keyword should already be one of the things we catch anyway. We may just want to remove content properties from the regular expression completely, right?

DiapDealer · 06-09-2020, 09:35 PM

I'm already checking for the presence of an url keyword, but after that's not found, I'm somehow "successfully" matching (and capturing) anything between two quotes (single or double) that doesn't contain backslashes or parens as a potential url that needs to be checked for updating.

That's not helpful at all!

DiapDealer · 06-09-2020, 09:37 PM

Quote:

Originally Posted by KevinH

Actually, the url keyword should already be one of the things we catch anyway. We may just want to remove content properties from the regular expression completely, right?

No. That first expression defines which property's values need to captured and searched for urls using the second expression. If we remove it completely. The content property will never be searched for urls.

KevinH · 06-09-2020, 09:42 PM

Then you do need that regex to capture what is in quotes as some css import and background images never use the "url()" wrapper.

KevinH · 06-09-2020, 09:43 PM

In fact I never understood where the url() wrapper was needed, and the use of quotes or no quotes.

DiapDealer · 06-09-2020, 10:01 PM

What if we tackled this from a different direction? Since nothing is actually being altered other than the url-encoding, can we detect whether the content has actually been modified and somehow skip the url encoding if it hasn't? As it is, it seems like the original content is always url encoded, and any new href (as a result of the renaming) is as well.

Surely there's a way that we can determine if--minus any url encoding--the content coming out is the same as the content that went in and either skip, or reverse the url encoding if nothing was actually updated?

06-09-2020, 07:32 PM	#1
sregiter Junior Member Posts: 2 Karma: 10 Join Date: Jun 2020 Device: Sigil	Garbled when renaming css file Hi, guys. I encounter the error on encoding when renaming css file, probably indicating a bug in the SIGIL as shows the following: [IMG]garbled.png[/IMG] SIGIL version: 1.2.0 Loaded Qt: 5.1.2.7: Buld time: 2020.03.28 00.:23:48 UTC Attached Thumbnails

06-09-2020, 09:08 PM	#8
KevinH Sigil Developer Posts: 8,478 Karma: 5703586 Join Date: Nov 2009 Device: many	According to some sources, if the content property is a url it should be wrapped in "url()". See this example from https://www.w3schools.com/cssref/pr_gen_content.asp Code: <!DOCTYPE html> <html> <head> <style> p::before { content: url(w3css.gif); } </style> </head> <body> <p>My name is Donald</p> <p>I live in Ducksburg</p> </body> </html> So if the "url()" wrapper is required for a url in a content property we should be able to restrict on that, right?

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Renaming an epub file	Frenchguy	Library Management	4	10-20-2017 03:18 AM
Garbled file titles on Save to Disk	rmkoske	Library Management	10	03-29-2015 12:52 PM
Extra CSS and class renaming	fenuks	Recipes	4	01-26-2014 05:24 AM
Renaming File Problem...	Howard098	Sony Reader	3	02-01-2010 10:57 PM
Gutenberg file renaming?	rdolmat	Sony Reader	9	01-06-2008 08:26 AM

06-09-2020, 07:42 PM	#2
DiapDealer Grand Sorcerer Posts: 28,358 Karma: 203720150 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	Hmmm. It's url encoding that property value for some reason. Might be something wrong with the regex that finds urls in css when renaming files/updating links. We'll have to do some investigating. Thanks for the report/sample.

06-09-2020, 07:51 PM	#3
DiapDealer Grand Sorcerer Posts: 28,358 Karma: 203720150 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	Does it change at all if you correct the syntax of your ::before ::after pseudo elements?

06-09-2020, 08:13 PM	#4
DiapDealer Grand Sorcerer Posts: 28,358 Karma: 203720150 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I can replicate it. The good news is that the url encoding doesn't actually affect the rendering of the generated content at all. But we'll still probably need to track down why it's happening.

06-09-2020, 08:17 PM	#5
sregiter Junior Member Posts: 2 Karma: 10 Join Date: Jun 2020 Device: Sigil	I corrected the syntax in the pseudo elements as you said, but the garbling still occurs.

06-09-2020, 08:27 PM	#6
DiapDealer Grand Sorcerer Posts: 28,358 Karma: 203720150 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	The content property is definitely one that gets parsed for urls to update when renaming files. But I can't immediately see why your non-url value is getting detected as an url. The regex is a bit convoluted. I'll have to stare at it for a while. But it's definitely getting detected as an url. That's the only reason the url-encoding would be applied. It's definitely a bug on our end.

06-09-2020, 08:41 PM	#7
DiapDealer Grand Sorcerer Posts: 28,358 Karma: 203720150 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I see it, but I definitely don't know what to do about it yet. As it stands, any content property's string value is always going to get url-encoded. But also as noted: rendering of the content is unaffected. By my estimation... any quoted string value in any of the css properties that CAN contain urls is always going to get url-encoded.

06-09-2020, 09:29 PM	#10
KevinH Sigil Developer Posts: 8,478 Karma: 5703586 Join Date: Nov 2009 Device: many	Actually, the url keyword should already be one of the things we catch anyway. We may just want to remove content properties from the regular expression completely, right?

06-09-2020, 09:35 PM	#11
DiapDealer Grand Sorcerer Posts: 28,358 Karma: 203720150 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I'm already checking for the presence of an url keyword, but after that's not found, I'm somehow "successfully" matching (and capturing) anything between two quotes (single or double) that doesn't contain backslashes or parens as a potential url that needs to be checked for updating. That's not helpful at all!

06-09-2020, 09:42 PM	#13
KevinH Sigil Developer Posts: 8,478 Karma: 5703586 Join Date: Nov 2009 Device: many	Then you do need that regex to capture what is in quotes as some css import and background images never use the "url()" wrapper.

06-09-2020, 09:43 PM	#14
KevinH Sigil Developer Posts: 8,478 Karma: 5703586 Join Date: Nov 2009 Device: many	In fact I never understood where the url() wrapper was needed, and the use of quotes or no quotes.

Advert

Advert

06-09-2020, 10:01 PM	#15
DiapDealer Grand Sorcerer Posts: 28,358 Karma: 203720150 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	What if we tackled this from a different direction? Since nothing is actually being altered other than the url-encoding, can we detect whether the content has actually been modified and somehow skip the url encoding if it hasn't? As it is, it seems like the original content is always url encoded, and any new href (as a result of the renaming) is as well. Surely there's a way that we can determine if--minus any url encoding--the content coming out is the same as the content that went in and either skip, or reverse the url encoding if nothing was actually updated?