The ability to rotate a picture clockwise

[SupraKarma]

Consider the following picture.


Some of the manuals display rotated. I got this from EmuMovies. Super Mario 64 (and I'm assuming many other common ones) do the same thing.

So, my suggestion is to implement some way to rotate an image. Preferably, something that doesn't involve mapping a new key, but I'd be happy with any solution.

 

[brolly]

Is that an image or pdf file?

 

[bleasby]

When you open the manual directly, in adobe acrobate for example, it displays rotated or not?
If it is still rotated, the problem is on the manual source that should be edited to display the pdf in the correct orientation.

If the original pdf is not rotated, please upload the pdf and post a log so we can try to figure out what could be done.

Sent from my SM-J200M using Tapatalk

 

[SupraKarma]

When you open the manual directly, in adobe acrobate for example, it displays rotated or not?
If it is still rotated, the problem is on the manual source that should be edited to display the pdf in the correct orientation.

If the original pdf is not rotated, please upload the pdf and post a log so we can try to figure out what could be done.

Sent from my SM-J200M using Tapatalk

I tried the manual in adobe acrobat, and it was normal (not rotated).

Here's a log. https://pastebin.com/tgm31qev

I've attached the .pdf file for Super Mario 64, not sure if I did that right.

 

[bleasby]

Thks SupraKarma.
It seams that there is a bug that, when changing the default dpi resolution, the layout from the original pdf file is lost in the conversion.
We will have to investigate if this is caused by the pause code, by the RL.dll code or by the ghostscript cmd.

 

[brolly]

Did you actually test this bleasby? Because this one also works fine for me:
http://imgur.com/a/a7KOt

SupraKama, please test with this manual and see if you get the same issue:
http://www.rlauncher.com/forum/showthread.php?4666-PDF-manual-pages-not-correct-orientation-in-Pause

The one thing consistent with both is that the first page is a single page while the rest are 2 pages side by side, but again everything works fine on my end. And I will also need a DLL log for this, make sure you enable it under the General Settings tab.
Also please verify if the generated png files are rotated or not.

 

[SupraKarma]

Yeah that manual has the same issue for me. It should be noted that I never seem to notice this issue for tall-paged manuals, so long as the first page is the same width as the subsequent pages. I suspect that may be part of the issue.

Anyways, here's the log. Let me know if there's anything more I can do to help.

https://pastebin.com/aAz1Gqur

Edit: The one thing I do specifically remember editing settings-wise is the PDF DPI resolution. I have it set much higher than the recommended settings, at 500 (some of my NES manuals looked substantially better after doing this).

Edit 2: I may have applied a fix that bleasby offered a while back for another problem in Pause, but I don't recall what it is offhand.

 

[brolly]

Alright that was it, if I set the dpi to 500 I can reproduce the problem will have a look at it when I have some time to see if I can figure what's going on. Meanwhile please try changing your dpi setting to 72 and confirm if they will display properly.

 

[SupraKarma]

At 72 the orientation is correct. I can't use those settings unfortunately, because it makes many of the correctly oriented manuals unreadable. 500 dpi may have been overkill, but I reasoned since it didn't affect performance, it would be ok. Maybe there's a threshold where it begins to cause problems?

 

[brolly]

Give it a try and see if you can find out where it starts to rotate, either way this needs to be fixed.

 

[SupraKarma]

The threshold for the Super Mario 64 (USA) manual is 85 dpi. At 85, it displays correctly, but 86 or higher and it will rotate.

 

[brolly]

Alright I think I got it sorted, replace your rocketlauncher.dll with this one and let me know if all is good:
http://s000.tinyupload.com/index.php?file_id=64206411879459657856

Make sure you delete the temp png files if you are leaving them cached.

 

[brolly]

@bleasby, this will require a change in Pause.ahk because if the user has Pause_LoadPDFandCompressedFilesatStart set to true this still won't work right on these cases. On pdf files like these we can't use this:
RLObject.generatePngFromPdf(element.Path1, RLMediaPath . "\" . SubMenuLabel . "\Temp\" . systemName . "\" . element.Label, Pause_SubMenu_PdfDpiResolution,pdfMaxHeight,1,0,Pause_PDF_Page_Layout)

Because when sending the settings to the GS library I can only define one page dimension which is applied to all pages so this obviously won't work, this call needs to be replaced with multiple dll calls one for each page. Should be a simple loop. I'd say we do this every time, the performance hit on the multiple dll calls should be negligible.

 

[SupraKarma]

Works great, thanks brolly!

 

[bleasby]

@bleasby, this will require a change in Pause.ahk because if the user has Pause_LoadPDFandCompressedFilesatStart set to true this still won't work right on these cases. On pdf files like these we can't use this:
RLObject.generatePngFromPdf(element.Path1, RLMediaPath . "\" . SubMenuLabel . "\Temp\" . systemName . "\" . element.Label, Pause_SubMenu_PdfDpiResolution,pdfMaxHeight,1,0,Pause_PDF_Page_Layout)

I will add it to my todo list if necessary brolly, but I have one question although.

I never define a per page dimension on the pause code or on any possible option.
The entire pdf always follow the same layout and resolution and height for all its pages.
So, it doesn't make sense to me to send multiple dll calls with the same info, when the only difference between them would be the page number.
Shouldn't anything like this be handled directly on the dll?
Ghostscript handled perfectly well all this cases when I used the command line directly instead of the dll, so I don't see why there wouldn't be an alternative to the solution of cluttering the code and adding multiple dll calls as in your suggestion.

 

[brolly]

I'm not sure what command line you used, but most likely you didn't feed it all parameters needed because if you are limiting the height of the PDF you'll need to pass it the png output size which is where things start screwing up.
What do you mean with "The entire pdf always follow the same layout and resolution and height for all its pages"? This is the problem here, the PDF doesn't not follow the same resolution for all pages, first one is different from all the others.

It could be done on the DLL I guess, but it would be even messier than doing in RL code I think, I can look into it I guess. I don't see why code would get cluttered in RL though, you'll still only make a DLL call in the code, the only difference is doing it inside a loop. Basically you'd only be adding a loop line much like the way you already do if Pause_LoadPDFandCompressedFilesatStart is set to false.

 

[bleasby]

I am referring to the output png files created. Not the original pdf properties.

When I used to do the conversion myself, the resulting output png file created by ghostscript would have always the same dpi for all pages of the manuals, and the original layout would be respected at the same time if the user kept the "frompdf" option selected.

Everything was handled by a single ghostscript command line. I dont recall if the maximum pdf pixels height was handled a priori or if it was something added when you made the conversion to use the dll instead. I need to check the old and current code to know more about that.

From what I understood of your loop suggestion, it would require as many dll calls as the number of pages to be created (one for each iteration inside the loop) instead of the current single dll call for the entire pdf, no?

Anyway, we should definetly move the discussion on how to handle that the best way possible to the developer forum.


Sent from my SM-J200M using Tapatalk

 

[brolly]

Are you talking about running the command line on this particular PDF file or some other one? Because it will only happen on this one because the page orientation differ from page 1 to the rest.

Yes it would need multiple dll calls, but only one actually dll call line in the code inside the loop (this is what you do already when generating the png files on the fly inside the pause menu). I can see if this can be done inside the DLL though, it will be a bit messier in that case.

And yeah let's move this to the dev forum.

 

[KenToad]

Alright I think I got it sorted, replace your rocketlauncher.dll with this one and let me know if all is good:
http://s000.tinyupload.com/index.php?file_id=64206411879459657856

Make sure you delete the temp png files if you are leaving them cached.

I'm having this problem and this file is no longer available.

Any help would be much appreciated.

 

[Styphelus]

Just came across this problem as well but the file is no longer available for download.Can someone re-upload it?