Considering the original volume of changes needed, we're about as okay as we can expect, but --- we still find branding issues. For example, today I found some more and I am pushing patches.
To resolve remaining branding issues we need the following:
* Some really smart person to grep the system properly looking for corrupt image files (png, xcf, jpg/jpeg, whatever else might be out there). We can't inspect those images for branding issues. For whatever reason, seems many of the images got corrupted with CR/LF issues. We have found most of the corrupt files (walch.martin found most of them --- I only pushed clean files), but I don't know of a good way to search the sources for corrupt image files.
(Note: Corrupt image files do not block building packages, but they cause usability issues that reflect badly on us).
* Some really smart person to grep the system looking for text strings containing KDE. I haven't figured out a slick way to search the sources for these branding issues. Again, I think we have found most but we continually find more, albeit a smaller number of these strings appear each time. The challenge is we *cannot* do a blind global search-and-replace. We are at the point where we have to review each potential suspect string in context to ensure we are updating human-viewable text strings and not code strings.
* Some really smart person to figure out how the fifteenpieces applet About dialog is sucking in a KDE3 branded image (bug report 1052). I don't know whether the problem is limited to fifteenpieces or whether the image being used is a global default About image. One way or another we need to find that image and update.
* Internationalization (tde-i18n) files are beyond me. I nonetheless have patched many of these files. Most of the changes have been in the nature of KDE->TDE, but I suspect that in those patches occasionally I presumed incorrectly and changed something that changed contextual meaning. I don't know how we are going to resolve the differences between the tde-18n files and the parent files in the main source tree (po files, *.desktop files, *.docbook files, etc.)
Darrell
On 06/27/2012 03:04 PM, Darrell Anderson wrote:
Considering the original volume of changes needed, we're about as okay as we can expect, but --- we still find branding issues. For example, today I found some more and I am pushing patches.
To resolve remaining branding issues we need the following:
- Some really smart person to grep the system properly looking for corrupt
image files (png, xcf, jpg/jpeg, whatever else might be out there). We can't inspect those images for branding issues. For whatever reason, seems many of the images got corrupted with CR/LF issues. We have found most of the corrupt files (walch.martin found most of them --- I only pushed clean files), but I don't know of a good way to search the sources for corrupt image files.
(Note: Corrupt image files do not block building packages, but they cause usability issues that reflect badly on us).
This is tricky. Using 'file' to test even the corrupt jpeg images will return a valid jpeg header in most cases and miss the fact that the image is corrupt. I don't mind grepping or running find tde/main -type f -name "*.jpg" -execdir <what> '{}' ;, but I need to know what <what> will do the trick. Ideas?
- Some really smart person to grep the system looking for text strings
containing KDE. I haven't figured out a slick way to search the sources for these branding issues. Again, I think we have found most but we continually find more, albeit a smaller number of these strings appear each time. The challenge is we *cannot* do a blind global search-and-replace. We are at the point where we have to review each potential suspect string in context to ensure we are updating human-viewable text strings and not code strings.
I'll give it a go. It will take either a recursive grep with an exclude or some global find with an -exec that uses file to test for searchable files -- or some combination of the two. Do you have any examples of what doesn't work so I don't reinvent a nonworking wheel :)
- Some really smart person to figure out how the fifteenpieces applet About
dialog is sucking in a KDE3 branded image (bug report 1052). I don't know whether the problem is limited to fifteenpieces or whether the image being used is a global default About image. One way or another we need to find that image and update.
Fun... I think I still have the old threads.
- Internationalization (tde-i18n) files are beyond me. (+1)
On 28 June 2012 15:05, David C. Rankin drankinatty@suddenlinkmail.comwrote:
On 06/27/2012 03:04 PM, Darrell Anderson wrote:
Considering the original volume of changes needed, we're about as okay
as we
can expect, but --- we still find branding issues. For example, today I
found
some more and I am pushing patches.
To resolve remaining branding issues we need the following:
- Some really smart person to grep the system properly looking for
corrupt
image files (png, xcf, jpg/jpeg, whatever else might be out there). We
can't
inspect those images for branding issues. For whatever reason, seems
many of
the images got corrupted with CR/LF issues. We have found most of the
corrupt
files (walch.martin found most of them --- I only pushed clean files),
but I
don't know of a good way to search the sources for corrupt image files.
(Note: Corrupt image files do not block building packages, but they cause usability issues that reflect badly on us).
This is tricky. Using 'file' to test even the corrupt jpeg images will return a valid jpeg header in most cases and miss the fact that the image is corrupt. I don't mind grepping or running find tde/main -type f -name "*.jpg" -execdir <what> '{}' ;, but I need to know what <what> will do the trick. Ideas?
use an image program to open the image that will error out and close if the file is corrupt. Check the return value of the program, if it exits with an error, then echo "blah blah blah" or something.
Calvin
On 06/28/2012 02:07 PM, Calvin Morrison wrote:
use an image program to open the image that will error out and close if the file is corrupt. Check the return value of the program, if it exits with an error, then echo "blah blah blah" or something.
Ahh 'feh' comes to mind... Thanks :)
use an image program to open the image that will error out and close if the file is corrupt. Check the return value of the program, if it exits with an error, then echo "blah blah blah" or something.
I thought about something like that, but I haven't figured out how to work around and trap the eventual error dialog.
We could use kuickshow or kview to test png, gif, and jpg/jpeg images; gwenview to test svg/svgz images; and the safest bet for xcf is gimp.
I haven't run any tests to see what kind of exit code those apps produce for success and failure.
A script run during the night would be nice:
test_tde_image () { for i in `find $GIT_SOURCES -name *.$FILE_TYPE`; do $IMAGE_APP $i # How to trap and close error dialogs? &>/dev/null? # Allow time for images to load? sleep 5 # How to close the app? EXIT_CODE="$?" if [ "$EXIT_CODE" != "0" ]; then echo "$i failed to open without error." >> $LOG_FILE fi done }
GIT_SOURCES=/path/to/GIT/sources LOG_FILE=/path/to/corrupt-tde-image.log touch $LOG_FILE
FILE_TYPE="png" IMAGE_APP=kuickshow test_tde_image
FILE_TYPE="gif" IMAGE_APP=kuickshow test_tde_image
FILE_TYPE="jpg" IMAGE_APP=kuickshow test_tde_image
FILE_TYPE="jpeg" IMAGE_APP=kuickshow test_tde_image
FILE_TYPE="svg" IMAGE_APP=gwenview test_tde_image
FILE_TYPE="svgz" IMAGE_APP=gwenview test_tde_image
FILE_TYPE="xcf" IMAGE_APP=gimp test_tde_image
Or something like that.
Darrell
On 28 Jun 2012, Calvin Morrison uttered the following:
use an image program to open the image that will error out and close if the file is corrupt.
Or use ImageMagick's identify(1), which will quit in both success and failure cases with different exit codes.
On Thu, 28 Jun 2012 14:05:10 -0500 "David C. Rankin" drankinatty@suddenlinkmail.com wrote:
On 06/27/2012 03:04 PM, Darrell Anderson wrote:
Considering the original volume of changes needed, we're about as okay as we can expect, but --- we still find branding issues. For example, today I found some more and I am pushing patches.
To resolve remaining branding issues we need the following:
- Some really smart person to grep the system properly looking for corrupt
image files (png, xcf, jpg/jpeg, whatever else might be out there). We can't inspect those images for branding issues. For whatever reason, seems many of the images got corrupted with CR/LF issues. We have found most of the corrupt files (walch.martin found most of them --- I only pushed clean files), but I don't know of a good way to search the sources for corrupt image files.
(Note: Corrupt image files do not block building packages, but they cause usability issues that reflect badly on us).
This is tricky. Using 'file' to test even the corrupt jpeg images will return a valid jpeg header in most cases and miss the fact that the image is corrupt. I don't mind grepping or running find tde/main -type f -name "*.jpg" -execdir <what> '{}' ;, but I need to know what <what> will do the trick. Ideas?
Check to see if <CR> appears separately anywhere in the file, without a trailing <LF>? If we're seeing a binary <-> text mode corruption problem, there won't be any separate <CR>s. Any file that's flagged as only containing the <CRLF> sequence should then be checked manually in an image viewer to make sure it's okay.
(I don't know how to do the above with grep etc., but the actual match takes 1 line in Perl.)
Check to see if <CR> appears separately anywhere in the file, without a trailing <LF>? If we're seeing a binary <-> text mode corruption problem, there won't be any separate <CR>s. Any file that's flagged as only containing the <CRLF> sequence should then be checked manually in an image viewer to make sure it's okay.
(I don't know how to do the above with grep etc., but the actual match takes 1 line in Perl.)
I was about to open khexedit and study a few image files when I realized that not all corruption errors will be caused by CR/LF issues. I'm thinking Calvin's approach might be best?
Darrell
On 28 June 2012 15:48, Darrell Anderson humanreadable@yahoo.com wrote:
Check to see if <CR> appears separately anywhere in the file, without a trailing <LF>? If we're seeing a binary <-> text mode corruption problem, there won't be any separate <CR>s. Any file
that's flagged
as only containing the <CRLF> sequence should then be checked manually
in an image viewer
to make sure it's okay.
(I don't know how to do the above with grep etc., but the actual match takes 1 line in Perl.)
I was about to open khexedit and study a few image files when I realized that not all corruption errors will be caused by CR/LF issues. I'm thinking Calvin's approach might be best?
Darrell
Try this:
Use image magicks tool called identify:
identify -v image-name | grep corrupt
if there is corruption it wil say something like "Corrupt Image" so just grep for it
Try this:
Use image magicks tool called identify:
identify -v image-name | grep corrupt
if there is corruption it wil say something like "Corrupt Image" so just grep for it
Ah yes, great thinking. :-) I had forgotten about imagemagick.
Good boy! Roll over! Get biscuit! :-)
Darrell
On 28 June 2012 16:05, Darrell Anderson humanreadable@yahoo.com wrote:
Try this:
Use image magicks tool called identify:
identify -v image-name | grep corrupt
if there is corruption it wil say something like "Corrupt Image" so just grep for it
Ah yes, great thinking. :-) I had forgotten about imagemagick.
Good boy! Roll over! Get biscuit! :-)
Darrell
On a OT note. ImageMagick rocks! It's ridiculously versatile. Right now I am using it to calculate the mode (most frequently occuring number in an array) by creating a histogram of each individual pixel across 18,000 images to generate a common background. Imagemagick does the heavy lifting in parts of it.
Calvin
Hi all,
On Thu, Jun 28, 2012 at 8:48 PM, Darrell Anderson humanreadable@yahoo.comwrote:
Check to see if <CR> appears separately anywhere in the file, without a trailing <LF>? If we're seeing a binary <-> text mode corruption problem, there won't be any separate <CR>s. Any file
that's flagged
as only containing the <CRLF> sequence should then be checked manually
in an image viewer
to make sure it's okay.
(I don't know how to do the above with grep etc., but the actual match takes 1 line in Perl.)
I was about to open khexedit and study a few image files when I realized that not all corruption errors will be caused by CR/LF issues. I'm thinking Calvin's approach might be best?
Sorry to dig this up. Has this been properly fixed? Also, has anyone found out when and why the corruption was introduced in the files? Could be necessary to adopt policies to further prevent that.
Best regards, Tiago
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Sorry to dig this up. Has this been properly fixed? Also, has anyone found out when and why the corruption was introduced in the files? Could be necessary to adopt policies to further prevent that.
Yes, these all were fixed long ago. How the corruption happened is a guess and nobody tried to investigate in any meaningful way.
Darrell
On Sun, Sep 16, 2012 at 1:34 AM, Darrell Anderson humanreadable@yahoo.comwrote:
Sorry to dig this up. Has this been properly fixed? Also, has anyone found out when and why the corruption was introduced in the files? Could be necessary to adopt policies to further prevent that.
Yes, these all were fixed long ago. How the corruption happened is a guess and nobody tried to investigate in any meaningful way.
Tks. I'll look into it sometime.
Tiago
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
- Some really smart person to grep the system properly
looking for corrupt image files (png, xcf, jpg/jpeg, whatever else might be out there). We can't inspect those images for branding issues. For whatever reason, seems many of the images got corrupted with CR/LF issues. We have found most of the corrupt files (walch.martin found most of them --- I only pushed clean files), but I don't know of a good way to search the sources for corrupt image files.
(Note: Corrupt image files do not block building packages, but they cause usability issues that reflect badly on us).
Regarding corrupt images, I believe we have that problem now behind us. Using a combination of find/xargs/identify I think I spotted any remaining suspects. There are thousands of image files in our repository, but I believe all now are viewable. Of course, the only sure-fire way to know would be to manually view each image file. :-)
That does not mean there are no branding issues with some images. Just yesterday I stumbled across one such image for ksysguard. There remains the mystery of the image in the fifteenpieces About dialog. Therefore images needing branding attention still exist.
Thank you everybody who have been helping with updating the images. I marvel at how quickly you folks update these images. :-)
Darrell
-
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
E. Liddell -
Nix -
Tiago Marques