You can download this release from sourceforge.net or check for updates in your existing installation.

There is a long list of enhancements and fixes - see change log below - some significant ones are:

- Rendering performance improvement with both LDView and LDGlite- Callouts are now freely movable on multi-step pages- All reproducible issues have been corrected - they were quite a few of them from legacy LPub- Platform upgrade to Qt 5.6 (MSVC 2015) which will position the application for better maintenance and evolutions going forward.

Screenshot:

Change Log:

LPub3D 2.0.1.717.2

Features and enhancements
------------
-Known Issue: Storing and retrieving the screen pos[ition] setting on multi-screen platforms causing a crash on startup. This feature has been disabled for the moment while I investigate. This unexpected behavior was introduced with the new version of Qt (development platform). The change you will notice is that the application will no longer start on the screen you closed it on last. Instead, it will will always start at x200 y200 on the main screen. Of course this issue is only related to multi-screen platforms. (r718)

LPub3D 2.0.1.717.2

Features and enhancements
------------
-Fix: In support of archive library move to AppData (see r707), the installation process will delete the 'old' LDRaw library archive directory even if it is actually the new directory. For example this can be reproduced if one attempts to reinstall LPub3D where the actual 'old' directory would have been deleted during the initial installation. The installation will now compare the 'old' directory to the new one and present the user the option to delete if the comparison does not match. (r715)
-Fix: At application launch, the 'Check for updates' does not detect the installed version. As a result, if the user performs a check for update or update checks are set to automatic, the user is presented with a message dialog stating a new update version is available when in fact this is not the case. The correct message dialog is now presented. Runaway eventloop when newest version is same as installed version. (r716)

LPub3D 2.0.0.714.2

Features and enhancements
------------
-Up to 60 percent increase rendering speed with configuration to render multiple files using a single call to LDView.
*All PLI (part list/BOM) parts for a given step are rendered in a single call versus individually. For CSI (Step models), all multi-step images on a page are rendered in a single call including callout(s). Single step page images are rendered with a single call for all model images including those in callout(s). This new configuration will default as checked in the preferences dialog.
*To achieve this behavior, input files (csi.ldr, pli.ldr) are now uniquely named because rendering multiple files is done by using -SaveSnapshots=1 instead of -SaveSnapshot=somefile.png and then listing all the LDR files at the end of the command line. There is no control over the output file names. Instead, LDView will automatically use the input base filename changing only the output filename extension from .ldr to .png.
*Enabling this feature is optional and can be selected on the Configuration/Preferences/Rendering tab by checking the box 'Use multiple files single call rendering' in the 'LDView is installed' group box. LDView must be installed and configured to enable this option.
*Notice: As this feature required a significant rewrite of the core image generation logic, it is likely to generate some unexpected behavior as not every scenario has been tested. Please report any unexpected behavior. Contact details can be found under the Help/About menu.
-Move LPub3D Ldraw archive libraries to AppData and rename unofficial library to lpub3dldrawunf.zip (r707)
*Archive libraries loaded automatically by ldraw during ldraw installation and is also distributed with portable media
*Archive libraries stored in user data (i.e. on Windows user/AppData/Local/Lpub3D Software/Lpub/libraries)
*LPub3D does not use parts from LDraw directory and ldconfig will fallback to the imbedded resource version if no LDraw directory is detected (This feature is not yet fully enabled. It is targeting a future enhancement)
*With exception of 'p' and 'parts', parts stored under .\LDraw\Unofficial are automatically added to lpub3d archive during application startup
*Lpub3d expects the official and unofficial library archive in the same directory.
*Lpub3d will prompt for archive file on startup if none is detected in the default expected location - this feature is targeted to support portable media and repackaged distributions (i.e. AIOI installations)
*If portable media installed in Program Files/(x86) folder, LPub3D will warn that it cannot place writable files at the default data location (folders under the installation directory) because UAC will prevent update access. This is useful for repackaged distributions (i.e. AIOI installations)
-Multi-step callouts are now movable (r656)
*Callouts on multi-step pages are now freely movable on the page.
-Add menu option to download official LDraw archive - unofficial archive was already available in v1.3.5 (r708)
*You can refresh both your official and unofficial LDraw library archives from the UI - As you may see from reading the change log, the aim is to over time allow LPub3D to be completely autonomous while maintaining it's ability to detect and consume unique and individual LDraw environment configurations.
-Add callouts, refactor and optimize LDView single call image generation, see r683,r684,r685 (r698)
*The LDView 'Single Call' rendering performance improvement will address parts list and model rendering for single step page, multi-step page and callouts - including divided pages/callouts. For example, a callout with 6 models, divided into 3 sections will send a single call to LDView to render all 6 model (CSI) images.
-Add progress bar to mpd/ldr file load (r690)
*Users can now see the progress of loading models. This is particularly useful for large models or models which include a large number of lines due to generated flex-parts etc...
-Enable 'Use multiple files single call rendering' for LDView from Preferences/Rendering/LDView is installed/Use Multiple files single call rendering. (r687)
*LDView 'Single Call' rendering performance improvement can be selected or unselected from the preferences dialog. Although I tested the as many scenarios as I can think of. If this new feature encounters some unique model file configuration that causes unexpected behavior, the user can revert back to the legacy functionality if s/he so desire.
-Increase PLI (Part list/BOM) and CSI (Model) rendering speed with LDView using -SaveSnapshots=1 (r683/r684/r685)
*'Single Call' performance improvement for LDView
-Redesign software and library update functionality (r710)
*Update architecture improved to allow archive library download during installation if no library is defined. This feature is positioned for mobile/packaged distributions (i.e. AIOI) distributions.
-Display application load progress during splash screen display (r676/r709)
*User can follow the application loading progress during startup launch
-Add context menu to pages without steps - e.g. Cover Page, BOM Page (r681)
*Pages without steps (e.g. Cover pages, BOM pages etc.) can be modified using the context menu. For example, to change background colour.
-Add missing context menu icons (r680)
*Small beautification enhancement - all context menu items now show a representative icon - this can be helpful when generating user guides for example.
-Suppress rotateIcon context menu item if rotate icon already inserted for step (r670)
*If a step already has an inserted rotate icon, the page/callout context menu will not present the option to add a rotate icon. Note: The option to delete a rotate icon presents from the context menu of the rotate icon itself and not from the Step/Callout's context menu.
-On a single-step page, place PLI (Parts List) on top of CSI (Model) images (r664)
*If a CIS (model) overlaps the PLI (parts list) the parts list will be presented on top so the instructions consumer can see all the parts implicated for the step presented. The reverse was previously the case.
-Upon reset image and model caches, reload current file, return to first page (r663)
*Reset cache options which clears all cache components (ldr, images, 3D views) will also reset the loaded file to the first page.
-Unique splash 3D model displayed during pdf printing, png, jpg and bmp image export (r657)
*Updated the 3D Viewer splash to reflect the format of output being generated - so an image depicting a pdf file will show when generating a pdf file and so on...
-ldglite update to 1.3.1 executable with -2g,2x option hardcoded for sharper images with offscreen rendering (r655)
*Incorporated the new ldglite renderer with 2x sampling for improved image quality
-Disable Clear Cache menu button when no file is loaded (r686)
*Just a little poka yoke. The cache locations are specific to the file loaded, so it does not help to have this button active when no file is loaded.
-Force to empty the cache before creating a PDF (r654)
*Added option to empty the image ldr and image cache before printing. With this feature the user can select the option on the print configuration dialog to clear the cache and regenerate images as the print/export job executes.
-Synchronize 'prev', 'next' and 'goto' page menu items (r653)
*User can enter directly any page number within range into the menu dialog. Clicking either the Previous or Next button will navigate to the page indicated regardless of if the page is the next increment backward (for Previous) or forward (for Next) or a page further backward or forward. The user can still hit the enter key to navigate to the indicated page - if not the current page of course.
-Suppress rotateIcon from CSI (model) item context menu if we have a callout and the callout assembled (r652)
*The menu option to insert a rotate step icon is not presented for assembled callouts.
-Select local page size and global and local page orientation - Portrait and Landscape (r518)
*Note: When manually editing the model file with either page size or orientation, it is recommended to insert both the size and orientation metas together. For example, even if you are only interested to add a page size, you shold update your file like the example
below - obviously selecting your own size values and orientation.
0 !LPUB PAGE SIZE GLOBAL 8.2677 11.6929
0 !LPUB PAGE ORIENTATION GLOBAL PORTRAIT
-Change: Page background context menu rearranged. "Change page background" and "Change Page Size or Orientation" now appear at the end of the menu list because they are likely to be least often used. (r641)
-Change: Point online manual to LPub3D content - was previously pointing to legacy LPub (r517)
-Refactor: Move library archives to AppData stabilization and robustness (r711)
-Refactor: Optimize fadeStep routines; change LDView logging details (r695)
-Refactor: Replace 0x050000 with QT_VERSION_CHECK(5,0,0) (r660)
-Refactor: Remove stretch/tile logic from coverImage management (r659)
-Refactor: Update CSI image mousePressEvent logic. (r640)
-Refactor: Update file load progress messages (r636)
-Refactor: Rearrange printToPdfFile page count (r632)
-Update: Clear 3D Window when there is no model to display - e.g. for cover or inserted pages (r701)
-Update: Set download dialog header to Library Updater when downloading library - otherwise Software Updater (r700)
-Update: AboutDialog window recognizes and displays Win 10 and OSX El Capitan(r665/r668/r669)
-Update: ldglite hard-coded default directory setting to ldglite1.3.1(r623)
-Update: 3DViewer minifig settings moved to ini file - LeoCAD Changeset 1870 (r617x)
-Fix: No image after initial generation when renderer other than LDView selected (r704)
-Fix: Set ldr load file to unofficial item by default (r691)
-Fix: Load inline submodels break (r688)
-Fix: Remove libpng warning: iCCP: known incorrect sRGB profile (r678)
-Fix: Convert special characters (copyright and trademark) from Wide Char to UTF8 for MSVC build (r677)
-Fix: Remove final colour model if exist when Fade Step is not enabled (r674)
-Fix: Clear cache when turning fade on/off (r674)
-Fix: FadeStep and preferCentimeter setting mixmatch (r674)
-Fix: Search directories not updated when directory added to Ldraw.ini (r673)
-Fix: When background is transparent context menu functionality is lost (fix is a hack which sets the bg-color to white with an alpha of 1.) (r672)
-Fix: When a CALLOUT allocation is changed, if you right-click a model in the callout and not the callout itself, the ALLOC meta is placed after the CALLOUT END and has no effect - meta appended but should be inserted (r650)
-Fix: Converting an assembly to a part results in a parse error when there are spaces in the file name (r649)
-Fix: If a divided STEP GROUP allocation is changed from vertical (Display as columns - default) to horizontal (Display as rows), selecting again Display as columns has no effect - meta appended but should be replaced (r648)
-Fix: When the "Redraw" icon is clicked on the LDraw File Editor window, the file editor resizes to 255x190 pixels (r647)
-Fix: Split BOM duplicates one part onto current and subsequent BOM pages (r646)
-Fix: Inserting a front cover page when the current first page is a multi step page (r645)
-Fix: Bug when using callouts in Multistep sequences. When you place your callout right from assembly, it appears on the left side. When you place your callout bottom, it appears on the top. (r643)
-Fix: wrong text when you export to PNG the window title says "Print to pdf" (r638)
-Fix: When publishing instructions with the option 0 !LPUB PAGE BACKGROUND TRANSPARENT a drop shadow layer was added (r637)
-Fix: Remove -w1 from default ldglite parms (r629)
-Fix: Periodic multi-step crash - 3DViewer image file line number mismatch (r628)
-Fix: Control manual page number entry (r627)
-Fix: Cleanup 'Copyright' and 'Trademark' unicode (utf8) chars on MSVC2015 build (r622)
-Fix: QPainter alphaChannel management - use setCompositionMode (r619/r620)
-Upgrade: With upgrade to Qt5x, moved to MSVC 2015 release builds to continue providing x85 and x64 builds as MinGW does not officially support x64 on Windows
-Upgrade: Updated development platform to Qt 5.6.1 (MSVC 2015) (r613)
-Upgrade: Updated Qt logging framework from Qt4x to Qt5x (r610)
-Upgrade: Updated development platform to Qt 5.5.1 (MinGW) (r608) -Upgrade: Updated development platform to Qt 5.5.1 (MinGW) (r608)

(2016-06-23, 6:51)Merlijn Wissink Wrote: Very, very nice Trevor!
I'll take a better look at the changelog and the new version itself later today, but it all sounds great (especially the speed improvement and the local page orientation).

Great work!

Many thanks Merlijn !

If you don't mind please let me know if you encounter any unexpected behavior.

As LPub3D 2.0 was ported to Qt 5.6 and from MinGW to MSVC 2015 means there is a significant possibility for platform and compatibility issues with legacy platforms (WinXP, Win7, Win8 etc...).

Wow! impressive changelog!!! - with many nice features
Another good thing is that the installer does no longer trigger Avast...
...but after installation (win7/64b) I get a message about missing MSVCP140.dll.

(2016-06-23, 11:07)Philippe Hurbain Wrote: Wow! impressive changelog!!! - with many nice features
Another good thing is that the installer does no longer trigger Avast...
...but after installation (win7/64b) I get a message about missing MSVCP140.dll.

Ah yes. welcome to .dll hell

I suspected there will be some dll backward compatibility issues as I am building and testing on Windows 10.

I will rebuild the distributions with all needed runtime dlls statically linked. This solution should prevent the behavior you experienced but I'm not certain for all platforms.

(2016-06-23, 11:07)Philippe Hurbain Wrote: Wow! impressive changelog!!! - with many nice features
Another good thing is that the installer does no longer trigger Avast...
...but after installation (win7/64b) I get a message about missing MSVCP140.dll.

Ah yes. welcome to .dll hell

I suspected there will be some dll backward compatibility issues as I am building and testing on Windows 10/Microsoft Visual Studio 2015.

I will rebuild the distributions with all needed runtime dlls statically linked. This solution should prevent the behavior you experienced but I'm not certain for all platforms.

Yup, this dll got out of hell... but now I get the failure below (and no, reinstalling doesn't fix).

Interesting - I thought I configured a clean deployment environment and I did not see any dependency on this platform plugin. Anyhow, I'm not surprised as this was required (albeit under a different name) with Qt4x distributions.

Ok so perhaps you can help me figure out the missing dependencies on your platform.

0. Prerequisite: Visual C++ Redistributable for Visual Studio 2015 installed.
1. Download a portable distribution of LPub3D i.e. LPub3D_x64-2.0.1.717.2_20160623.zip
2. Extract it to your C:\ so as to have C:\LPub3D_x64\*
3. Extract and add the attached .dll qwindows.zip into to platforms subfolder so as to have C:\LPub3D_x64\platforms\qwindows.dll
4. Try to launch and let me know if you receive other dependency prompts or if successful to launch

(2016-06-23, 18:13)Merlijn Wissink Wrote: I had the same issue as Philo (windows platform issue).
After following your steps, it kinda works. It mostly crashes directly after the splash-screen, but sometimes it does start up...

Ok - thanks for the update. I'm repackaging the distributions just as Qt/Microsoft recommends. I imagine this will solve some problems.

The crash right after the splash-screen sounds familiar.

What version of Windows are you running? How many screens do you have?

If you are comfortable with manipulating your Windows Registry. Follow these steps and let me know if the crash consistently persists:

1. Navigate to Computer\HKEY_CURRENT_USER\SOFTWARE\LPub3D Software\LPub3D\MainWindow
2. Delete the String Value "pos" if it exist (in fact you may remove all the values in this key as the safe ones will be automatically regenerated the next time the application starts.)

If you are experiencing the issue I think you are here is a background:
Known Issue: Storing and retrieving the screen pos[ition] setting on multi-screen platforms causing a crash on startup. This feature has been disabled for the moment while I investigate. This unexpected behavior was introduced with the new version of Qt (development platform). The change you will notice is that the application will no longer start on the screen you closed it on last. Instead, it will will always start at x200 y200 on the main screen. Of course this issue is only related to multi-screen platforms. (r718)

I'm using Windows 10 Pro 64bit. And, I'm using 1 screen, although at a relatively uncommon resolution. I used to have 2 1080p monitors for years, but I recently switched them for 1 'ultrawide' monitor with a resolution of 3440x1440.

Got back home, so I try on another machine (win7 home 64b). Here I had trouble installing VCredist (it says that it failed but seems installed nonetheless) so maybe part of the issues comes from that. When I launch LPub3d I get another missing DLL: api-ms-win-crt-runtime-l1-1-0.dll

(2016-06-23, 18:52)Philippe Hurbain Wrote: Got back home, so I try on another machine (win7 home 64b). Here I had trouble installing VCredist (it says that it failed but seems installed nonetheless) so maybe part of the issues comes from that. When I launch LPub3d I get another missing DLL: api-ms-win-crt-runtime-l1-1-0.dll

Ah, yes. I was just looking at the list of dependent items and the dll you list is one of them. I'm working on repackaging the distributions to account for all the dependent items.

I'll try to have an updated release by the end of the night.

As you can see it is invariably more complex to make things more simple

I have repackaged the distributions to deploy the required Qt MSVC plugins and automatically detect and install the MS VC++ runtime dependencies.

However, there remains a nagging issue of intermittent crashes at startup. I'm convinced it is linked to the exchange between Qt and the OS but I have not yet found the source of the problem - even after several debugging sessions and a ton or research.

If you experience a crash (or series of crashes), just restart the application a few times. You may encounter about 1-4 crashes back-to-back and then the application will launch again normally. This is a very strange issue.

I can say with version 2.0, I am reminded of why I dislike so much the Visual Studio/Visual C++ dev platform

As before, you can download from Sourceforge.net or run check for updates from within the application.

Up-to-date change log:

LPub3D 2.0.2.721.2

Features and enhancements
------------
-Fix: Add all Visual C++ dependencies to installation and portable distributions including VC++ 2015 redistributable runtime libraries (r720)
*Repackaged all distributions to incorporate all MSVC 2015 required dependency libraries. The Visual C++ Redistributable for Visual Studio 2015 is also included in the portable distributions. For the executable installation distribution, the installation program will check if the required libraries exist before silently installing the respective Visual C++ redistributable.
-Known Issue: Storing and retrieving the screen pos[ition], size, state and geometry settings appear to be causing intermittent crash on startup - at the end of the splash screen display. (r718/r719)
*This functionality has been disabled for the moment while I investigate. This unexpected behavior was introduced with the Qt5.6/MSVC 2015 development platform. The change you may notice is that the application no longer starts on the screen you last close it. Instead, it will will always start at the same location. While I have experienced this behavior on a multi-screen display configuraion, there are reports that this behavior also exist on single-screen displays.
-Fix: Disable search directory validation in Preferences dialog - temporary workaround (r721)
*Warnings are displayed when there are no unofficial subdirectories under the LDraw directory. In such case no warnings should be displayed.

This is super weird.
I updated the application (although using SourceForge, since the included updater didn't do anything for some reason).

I started the application. It crashed, I started it again, it started successfully. Then I closed it again and started it again, it crashed again.

Everytime it crashes, one of those standard Windows popups appears where you can either 'close the application' or 'debug' (or whatever it's called in English, my Windows is set to Dutch). So, for once I pressed the debug button instead of the close button. Nothing happened, except that LPub3D magically did start up...

Now, it doesn't crash a single time at start-up (or i'm incredibly lucky). I've started it like 20 or 30 times in a row now and not a single crash. I cannot think of any way how that single Windows button (that seemingly did nothing) fixed it

(2016-06-24, 7:04)Merlijn Wissink Wrote: This is super weird.
I updated the application (although using SourceForge, since the included updater didn't do anything for some reason).

I started the application. It crashed, I started it again, it started successfully. Then I closed it again and started it again, it crashed again.

Everytime it crashes, one of those standard Windows popups appears where you can either 'close the application' or 'debug' (or whatever it's called in English, my Windows is set to Dutch). So, for once I pressed the debug button instead of the close button. Nothing happened, except that LPub3D magically did start up...

Now, it doesn't crash a single time at start-up (or i'm incredibly lucky). I've started it like 20 or 30 times in a row now and not a single crash. I cannot think of any way how that single Windows button (that seemingly did nothing) fixed it

Well you are experiencing the exact same behavior I am. And like you I find it very strange. More so that I'm not able to find the reason for the problem but I believe I know the source.

I don't think it is the end of your crashes, but let's see. In the mean time, I'm continuing to look for the problem source. Hopefully I can have it resolved this weekend.

(2016-06-24, 18:35)Trevor Sandy Wrote: Well you are experiencing the exact same behavior I am. And like you I find it very strange. More so that I'm not able to find the reason for the problem but I believe I know the source.

I don't think it is the end of your crashes, but let's see. In the mean time, I'm continuing to look for the problem source. Hopefully I can have it resolved this weekend.

Cheers,

This might be caused by an uninitialized variable as debug version/runs usually zero out those while a releases optimized that out. A crash is then left to chance as it depends on the value the variable happens to get on program start.

Don't know how this works combined with a single (non debug) exe though but the debugger might have wiped the used memory or something.

(2016-06-24, 18:35)Trevor Sandy Wrote: Well you are experiencing the exact same behavior I am. And like you I find it very strange. More so that I'm not able to find the reason for the problem but I believe I know the source.

I don't think it is the end of your crashes, but let's see. In the mean time, I'm continuing to look for the problem source. Hopefully I can have it resolved this weekend.

Cheers,

This might be caused by an uninitialized variable as debug version/runs usually zero out those while a releases optimized that out. A crash is then left to chance as it depends on the value the variable happens to get on program start.

Don't know how this works combined with a single (non debug) exe though but the debugger might have wiped the used memory or something.

Hi Roland - Actually to give some context on this issue. I saw it the first time after porting to Qt 5.6. This version of Qt introduced a lot of changes to the way graphics drivers are managed on Windows. Some of these changes I don't think are very backward compatible (at least, not without a great deal of rework).

Anyway, this issue first presented with I set the application to force the use of OpenGL (myApp.setAttribute(Qt::AA_UseDesktopOpenGL)) versus using ANGLE which is the Windows-friendly default. However, using ANGLE is not an option as my imbedded LeoCAD module performs direct OpenGL calls. Nevertheless, ANGLE is still somehow a dependency.

I can consistently reproduce the crash if I enable the following MainWindow management code which worked without issue on Qt 4.8:

With this code, the application will launch without issue the first time. Once I move the window (let's say to another screen - Point(4121 161)) the application will crash. It is as if the pos coordinates become out of bounds or something.

The debugger points to a ScopedPointer problem relates to window management but I can't make heads or tails about where the problem is starting from. The picture below show a view of the debugger at the segmentation fault.

The interesting thing is when I disable the above code the crash is no longer consistent but becomes intermittent - as I have described it above and in the release notes.

The debugging prompt when you encounter the error is just the operating system recognizing that a crash dump file is available and prompting the user to launch whichever application on the system that is designated for debugging.

(2016-06-25, 0:11)Trevor Sandy Wrote: With this code, the application will launch without issue the first time. Once I move the window (let's say to another screen - Point(4121 161)) the application will crash. It is as if the pos coordinates become out of bounds or something.

The debugger points to a ScopedPointer problem relates to window management but I can't make heads or tails about where the problem is starting from. The picture below show a view of the debugger at the segmentation fault.

The interesting thing is when I disable the above code the crash is no longer consistent but becomes intermittent - as I have described it above and in the release notes.

The debugging prompt when you encounter the error is just the operating system recognizing that a crash dump file is available and prompting the user to launch whichever application on the system that is designated for debugging.

(2016-06-24, 18:35)Trevor Sandy Wrote: Well you are experiencing the exact same behavior I am. And like you I find it very strange. More so that I'm not able to find the reason for the problem but I believe I know the source.

I don't think it is the end of your crashes, but let's see. In the mean time, I'm continuing to look for the problem source. Hopefully I can have it resolved this weekend.

Cheers,

Well, it actually was the end of my crashes. Over the course of yesterday I started LPub3D regularly to see if it crashed, but it started successfully 100% of the time. In fact, I was able to load models, create instructions, everything*.

Today I started the computer again, I started LPub3D. And.... it crashed. But, I performed my 'fix' and it's working again without any crashes*.

*I actually did found a crash (but it seems unrelated to the start-up issue): if I try to load an LDraw file without any steps (either a part or just a model without steps). LPub3D crashes. After a restart, I have to perform my 'fix' again in order for it to work again.

(2016-06-24, 18:35)Trevor Sandy Wrote: Well you are experiencing the exact same behavior I am. And like you I find it very strange. More so that I'm not able to find the reason for the problem but I believe I know the source.

I don't think it is the end of your crashes, but let's see. In the mean time, I'm continuing to look for the problem source. Hopefully I can have it resolved this weekend.

Cheers,

Well, it actually was the end of my crashes. Over the course of yesterday I started LPub3D regularly to see if it crashed, but it started successfully 100% of the time. In fact, I was able to load models, create instructions, everything*.

Today I started the computer again, I started LPub3D. And.... it crashed. But, I performed my 'fix' and it's working again without any crashes*.

*I actually did found a crash (but it seems unrelated to the start-up issue): if I try to load an LDraw file without any steps (either a part or just a model without steps). LPub3D crashes. After a restart, I have to perform my 'fix' again in order for it to work again.

Very well - if you can PM me an example of the file you are using the generate the LDraw crash it will help me to faster find the problem.

I tested a large flattened file from Philo and I did not have any problems. In fact I just loaded this file now again successfully after my recent updates:- see screenshot below:

I used a few random .dat part files on my desktop, and this file. All of them made LPub crash. When I used another .mpd it didn't crash. The only difference between the not-crashing .mpd and the other files is that the working one has steps. So, I figured the missing steps might be a problem?

The minidump says it's exception code 0xC0000005 with exception information:
The thread tried to read from or write to a virtual address for which it does not have the appropriate access.

(2016-06-26, 7:52)Merlijn Wissink Wrote: I used a few random .dat part files on my desktop, and this file. All of them made LPub crash. When I used another .mpd it didn't crash. The only difference between the not-crashing .mpd and the other files is that the working one has steps. So, I figured the missing steps might be a problem?

Looks like the meta command '0 NOFILE' is missing from the end of your last '0 FILE...' in the mpd.

The problem is corrected in 2.0.3. There is a block of logic that checks if fade step is turned on in which case it will insert a last page with the final unfaded model. In doing this check at the end of the mpd, if the last line in the main ldr starts with 1 - 5, the application will produce this error. If the last line starts with 0 (such as 0 NOFILE, 0 STEP ....) the behavior will be as expected. The problem was I am doing a line check after the last 1 - 5 line which may not exist- hence the crash.

(2016-06-24, 7:04)Merlijn Wissink Wrote: This is super weird.
I updated the application (although using SourceForge, since the included updater didn't do anything for some reason).

I started the application. It crashed, I started it again, it started successfully. Then I closed it again and started it again, it crashed again.

Everytime it crashes, one of those standard Windows popups appears where you can either 'close the application' or 'debug' (or whatever it's called in English, my Windows is set to Dutch). So, for once I pressed the debug button instead of the close button. Nothing happened, except that LPub3D magically did start up...

Now, it doesn't crash a single time at start-up (or i'm incredibly lucky). I've started it like 20 or 30 times in a row now and not a single crash. I cannot think of any way how that single Windows button (that seemingly did nothing) fixed it

Just a note - the updater is now configurable. The default status is to do nothing (perhaps I should change this) so you have to configure your preferences and you'll be able to visually track your update check. Here is a screenshot:

(2016-06-24, 5:37)Trevor Sandy Wrote: I have repackaged the distributions to deploy the required Qt MSVC plugins and automatically detect and install the MS VC++ runtime dependencies.

Just installed LPub3D-2.0.4.737.2_20160702 to have a first look around for the upcoming AIOI. Win10 reports the following .dll missing:

VCRUNTIME140.dll
MSVCP140.dll

w.

BTW: How do I divide a large BOM over several pages. Say you'll list the BOM for the Cafe Corner?

I can think of only one scenario where you can experience this behavior which is if you select the MSVC 'portable' distribution - the one that does not have MinGW in the name :-) - unzip the archive, and proceed directly to launch the LPub3D executable.

Under this approach you would have missed the prerequisite of installing the Visual Studio 2015 runtime. If you look in the installation root directory, you will see vc_redist.x86[64].exe. It is necessary to manually install the contents of this package (or have a previous installation) before running LPub3D from a portable distribution.

With the NSIS installer-packaged distribution, the installer will automatically look in your System32 directory for vcruntime140.dll. If it is not found, the installer will proceed to install vc_redist.x86[64].exe. You can see the details of this activity if you select to show details during the install files dialog when the installer is running.

I have updated sourceForge with the source for version 2.0.4. You can look under tools/Win-setup to find '00 BuildLPub3D00AndCreateDistNoPack.bat' and 'LPub3DNoPack.nsi'. These are the scripts used to package all distributions of LPub3D and should help you with your AIOI packaging - particularly the latter script.

Let me know if this information resolves your issue.

To divide a bom, simply right click the BOM and select 'Split Bill of Materials' from the context menu. See image.

(2016-07-05, 20:53)Trevor Sandy Wrote: Under this approach you would have missed the prerequisite of installing the Visual Studio 2015 runtime. If you look in the installation root directory, you will see vc_redist.x86[64].exe. It is necessary to manually install the contents of this package (or have a previous installation) before running LPub3D from a portable distribution.

With the NSIS installer-packaged distribution, the installer will automatically look in your System32 directory for vcruntime140.dll. If it is not found, the installer will proceed to install vc_redist.x86[64].exe. You can see the details of this activity if you select to show details during the install files dialog when the installer is running.

I have updated sourceForge with the source for version 2.0.4. You can look under tools/Win-setup to find '00 BuildLPub3D00AndCreateDistNoPack.bat' and 'LPub3DNoPack.nsi'. These are the scripts used to package all distributions of LPub3D and should help you with your AIOI packaging - particularly the latter script.

Hi Trevor,

many thanks for the insight. I'll see if the:

IfFileExists "$Windir\System32\vcruntime140.dll"

is enough or if the installer prog I work with comes with some additional tricks.

Looking through the script I noticed that you install a "lpub3dldrawunf.zip". I presume it is a copy of the ldrawunf.zip. You will surely have noticed that we do not distribute "unofficials" along with the LDraw Parts Library or in the AIOI, but just offer the download with the appropriate warning because of their delicate nature. The .zip comes with no license and is not meant to be redistributed as the official library.

(2016-07-05, 20:53)Trevor Sandy Wrote: Under this approach you would have missed the prerequisite of installing the Visual Studio 2015 runtime. If you look in the installation root directory, you will see vc_redist.x86[64].exe. It is necessary to manually install the contents of this package (or have a previous installation) before running LPub3D from a portable distribution.

With the NSIS installer-packaged distribution, the installer will automatically look in your System32 directory for vcruntime140.dll. If it is not found, the installer will proceed to install vc_redist.x86[64].exe. You can see the details of this activity if you select to show details during the install files dialog when the installer is running.

I have updated sourceForge with the source for version 2.0.4. You can look under tools/Win-setup to find '00 BuildLPub3D00AndCreateDistNoPack.bat' and 'LPub3DNoPack.nsi'. These are the scripts used to package all distributions of LPub3D and should help you with your AIOI packaging - particularly the latter script.

Hi Trevor,

many thanks for the insight. I'll see if the:

IfFileExists "$Windir\System32\vcruntime140.dll"

is enough or if the installer prog I work with comes with some additional tricks.

Looking through the script I noticed that you install a "lpub3dldrawunf.zip". I presume it is a copy of the ldrawunf.zip. You will surely have noticed that we do not distribute "unofficials" along with the LDraw Parts Library or in the AIOI, but just offer the download with the appropriate warning because of their delicate nature. The .zip comes with no license and is not meant to be redistributed as the official library.

w.

Willy - Indeed, I use 2 archive library files, complete.zip which I use as-is, and lpub3dldrrawunf.zip which is used to store all non-official content. This includes generated fade files, custom part 'assemblies', or any content found within the LDraw\Unofficial directory (other than parts under 'p' or 'parts' subdirectories). Keep in mind the purpose of LPub3D is to generate instructions so, I have found, sometimes it's necessary to create custom part configurations.

Of course I could use an empty archive file with just the folder structure (no LDraw unofficial content) whereby the user can choose to pull single files or whatever into their archive by simply placing them at the appropriate location under their Unofficial directory; however, to keep the behaviour efficient, I load the full archive. There is functionality form the UI menu to update the archive files, in their entirety, at any time which will allow the user to sync with LDraw anytime they want.

I'm not sure I understand everything about all the sensitivity and licensing stuff. For me, the content is freely available, and it adds efficiency to include it in the package. Of course, as you have said, there are pitfalls with the unofficial content so it's inclusion must be done in a way that maintains flexibility, exclusion from official content and efficient update.

I'm installing LPub 2.0 on Vista. I have User Access Control enabled for my user code, so when I run the installation, it prompts me for my administrator password. As a result, it then seems to be creating the "libraries" folder within the AppData folder hierarchy of the admin user [admin\AppData\Local\LPub3D Software\LPub3D\libraries]. Once the installation completes, I run LPub 2.0 with my normal (i.e.non-elevated) user id. It searches for the "libraries" folder within the AppData folder hierarchy applicable to my user id [%USERPROFILE%\AppData\Local\LPub3D Software\LPub3D\libraries]. This folder does not exist.

Is there a requirement to run LPub3D as the admin user? If not, how does one configure the installation to create the libraries subfolder and content within the user profile folder hierarchy for my user id rather than that for the admin user?

I'm installing LPub 2.0 on Vista. I have User Access Control enabled for my user code, so when I run the installation, it prompts me for my administrator password. As a result, it then seems to be creating the "libraries" folder within the AppData folder hierarchy of the admin user [admin\AppData\Local\LPub3D Software\LPub3D\libraries]. Once the installation completes, I run LPub 2.0 with my normal (i.e.non-elevated) user id. It searches for the "libraries" folder within the AppData folder hierarchy applicable to my user id [%USERPROFILE%\AppData\Local\LPub3D Software\LPub3D\libraries]. This folder does not exist.

Is there a requirement to run LPub3D as the admin user? If not, how does one configure the installation to create the libraries subfolder and content within the user profile folder hierarchy for my user id rather than that for the admin user?

Regards,

David

David - There is no requirement to run LPub3D as the admin user. However, Admin-level access is needed to install a program on modern versions of Windows.

This access is usually resolved by the logged in user accepting the famous 'Do you want to allow the following program...to make changes to this computer?' message:

Of course the logged in user must be enabled with the rights to install programs. For me, I set my logged in user as an administrator:
1. Under Control Panel=>User Accounts
2. Select Change your account type
3. Select Administrator on the dialog presented which should look something like this (this is a Win10 version):

[Solution Option 1]
With these settings in place you can install programs under your logged in user credentials and, in the case of LPub3D, will be able to deposit the LDraw archive libraries and other updatable content to the local AppData directory of the logged in user.

[Solution Option 2]
Alternatively, if you can accept to hack the system. You can do the following:

1. Logged in as Administrator - so you can access the local AppData directory - move[admin\AppData\Local\LPub3D Software\LPub3D\libraries] to the same location for the usual logged in user so as to have [<logged in user>\AppData\Local\LPub3D Software\LPub3D\libraries]
2. Log out as Administrtor and log in as logged in user
3. Start LPub3D and you will receive a prompt that the archive library directory cannot be found with a dialog to select the new location.
4. Select the location created in step 1.
Note: The behavior here is that LPub3D will write a registry entry 'PartsLibrary' capturing the location of the archive library 'complete.zip'. When you move the library as you did in step 1. LPub3D will inform you that it cannot find the library and prompt you to select a new location. If the location is valid (i.e. it contains complete.zip), LPub3D will update the registry entry 'PartsLibrary' with this new location. Keep in mind that sufficient access rights will be necessary to update the registry but this should not be a problem (assuming your access control settings have not been altered) as the application owner (system) will be making this update.
If you select cancel at the library prompt, you will receive a further prompt to create the library folder (under the logged in user) and download the libraries automatically. However, as your logged in user may not have sufficient rights to do these actions, it is not advised that you select this option.

[Solution Option 3]
A third alternative is to create the library archive folder wherever you want and update the registry entry [Computer\HKEY_CURRENT_USER\SOFTWARE\LPub3D Software\LPub3D\Settings\PartsLibrary]:
1. Launch regedit (you'll need to be logged in with the appropriate access control to do this)
2. Navigate to the location above and update the Value data by changing only the location path to the new path so and example would be from [C:\Users\Administrator\AppData\Local\LPub3D Software\LPub3D\libraries\complete.zip] to [C:\LPub3D\libraries\complete.zip].

Based on what David wrote, I think you misunderstood. Try this on your home computer:

Totally uninstall LPub3D

Create a limited user account (one that doesn't have admin rights; note that I think this is recommended by Microsoft for all everyday user accounts now*).

Log into the limited user account.

Install LPub3D. When prompted, select an admin account and enter that account's password.

Try to run LPub3D.

Now, I haven't done the above, but based on what David reported, I'm pretty sure LPub3D will fail to run. That's what he meant when he asked if LPub3D requires the user to be an admin in order to run it. I suspect that right now it does, and that this wasn't done intentionally.

(2016-06-28, 4:14)Travis Cobbs Wrote: Based on what David wrote, I think you misunderstood. Try this on your home computer:

Totally uninstall LPub3D

Create a limited user account (one that doesn't have admin rights; note that I think this is recommended by Microsoft for all everyday user accounts now*).

Log into the limited user account.

Install LPub3D. When prompted, select an admin account and enter that account's password.

Try to run LPub3D.

Now, I haven't done the above, but based on what David reported, I'm pretty sure LPub3D will fail to run. That's what he meant when he asked if LPub3D requires the user to be an admin in order to run it. I suspect that right now it does, and that this wasn't done intentionally.

I don't know if they have since changed their mind about the above or not, but I have definitely run into programs that didn't run in "standard user" accounts.

Ok - Thanks Travis. Ary your directing your instructions above to me or David? If me, are you suggesting that LPub3D might inadvertently require admin rights to run and I should look at changing this ?

(2016-06-28, 13:50)Trevor Sandy Wrote: Ok - Thanks Travis. Ary your directing your instructions above to me or David? If me, are you suggesting that LPub3D might inadvertently require admin rights to run and I should look at changing this ?

Cheers,

I'm directing the instructions to you, Trevor. And yes, that's what I'm suggesting. Based on what David wrote, it appears that LPub3D doesn't work for standard user accounts, and this is generally a bad thing. Bear in mind, as I mentioned, I didn't personally follow the steps, so it could be something else, but that's what it seems to be.

(2016-06-28, 13:50)Trevor Sandy Wrote: Ok - Thanks Travis. Ary your directing your instructions above to me or David? If me, are you suggesting that LPub3D might inadvertently require admin rights to run and I should look at changing this ?

Cheers,

I'm directing the instructions to you, Trevor. And yes, that's what I'm suggesting. Based on what David wrote, it appears that LPub3D doesn't work for standard user accounts, and this is generally a bad thing. Bear in mind, as I mentioned, I didn't personally follow the steps, so it could be something else, but that's what it seems to be.

Hi Trevor,

Travis' description is spot on.

Given the release on 2.0.3, I uninstalled 2.0.2 as a separate step and then installed 2.0.3 from scratch. After the install, it had created the "LPub3D Software" directory hierarchy and contents under the admin "AppData\Local" user. I copied the content to the corresponding "AppData\Local" directory under my non-admin user. While this appears to resolve my install, it "feels" wrong.

(2016-06-28, 4:14)Travis Cobbs Wrote: Based on what David wrote, I think you misunderstood. Try this on your home computer:

Totally uninstall LPub3D

Create a limited user account (one that doesn't have admin rights; note that I think this is recommended by Microsoft for all everyday user accounts now*).

Log into the limited user account.

Install LPub3D. When prompted, select an admin account and enter that account's password.

Try to run LPub3D.

Now, I haven't done the above, but based on what David reported, I'm pretty sure LPub3D will fail to run. That's what he meant when he asked if LPub3D requires the user to be an admin in order to run it. I suspect that right now it does, and that this wasn't done intentionally.

I don't know if they have since changed their mind about the above or not, but I have definitely run into programs that didn't run in "standard user" accounts.

Ok - Thanks Travis. Ary your directing your instructions above to me or David? If me, are you suggesting that LPub3D might inadvertently require admin rights to run and I should look at changing this ?

Cheers,

I setup and executed this test as Travis described and LPub3D installed and ran successfully. However, as David pointed out, the data directory was created under the Administrator profile - and not the logged in user's profile as would be expected.

So at this time, I conclude that LPub3D does not require the user to be an Administrator to run.

I will look into why the installer program follows the Administrator profile and not the logged in user to setup the data directory during installation. If I understand correctly, I think this is the issue David is trying to solve?

(2016-06-29, 17:50)Trevor Sandy Wrote: I will look into why the installer program follows the Administrator profile and not the logged in user to setup the data directory during installation. If I understand correctly, I think this is the issue David is trying to solve?

Hi Trevor,

that is the issue I'm suggesting to try to solve since when LPub3D is run following the install, it fails to find the "libraries" folder because it is in the admin user profile rather than the non-admin user profile. It's not a huge problem because of the manual workaround to copy the folder from the admin to the non-admin user profile but correcting it would make the initial use of LPub3D a little smoother.

You can download this LPub3D 2.0.3 from sourceforge.net or check for updates in your existing installation.

LPub3D 2.0.3.729.1

Features and enhancements
------------
-Change: Check for update settings are now enabled by default. Previously, it was necessary to configure update settings in the Preferences/Other tab before one could visually confirm an update check. (r722)
-Fix: Warnings are displayed when there are no unofficial subdirectories under the LDraw directory. (r723)
*When no search directories are defined (i.e. No Unofficial or Models directories exist) and the user opens the Preferences dialog, teh LDraw Content Search Directories dialog will validate an empty dialog with a warning that the 'entry' is an invalid search directory. In such case no warnings should be displayed.
-Fix: Installation program presents options to delete 'old' library directory on new installation when no old directory existed. (r724)
*Comparison of old and new are not the same evaluated to true. Comparison improved to check that old is actually a directory also.
-Change: Preferences/Other/Check for updates/Version now presents all valid updatable versions in a dropdown list. (r725,r728)
*Manage better the update dialog. Restrict entries to only valid update versions.
-Fix: Crash when last line in main model of mpd file is a part type line - i.e. line starts with 1 to 5. (r726)
*This behavior will be seen when the user loads a model file without the meta tag '0 STEP' or '0 NOFILE'.
-Fix: Export and PDF generation produces "Failed to create CSI" and does not produce model images in the generated document.(r727) *Temporary testing code blocked the creation of CSI images - my apologies:-(

(2016-06-30, 17:46)Roland Melkert Wrote: Trevor have you tried using MinGW(64) to compile LPub3D ? it will remove all the visual studio run time dependencies and probably make code more portable too (if any changes are needed).

Roland, Thanks for the link. I was using the x32/x64 Qt MinGW distributions hosted on SF before moving to Qt 5.6. However, they stopped providing the x64 builds at I believer Qt 5.1. I couldn't get the LeoCAD library to compile on that version.

I decided to move to MSVC to be able to keep providing x64 distributions on Qt 5.6. I noticed a link on the url you sent that has a pre-built Mingw x64 for Qt 5.6.

"Alternate QT 5.6.0 build by MultipleMonomials because the link above has broken: here. (Compiled with TDM-GCC-64 and cygwin64, no ANGLE) (includes libgcc, winpthread, and libstdc++ DLLs)"

I'll take a look and see if I can use that. I've been checking regularly to see if I could find a mingw x64 Qt 5.6 distribution so it's good that something finally popped up.

The code remains as portable as I can keep it developing exclusively on Windows for the moment. In fact, I continue develop on mingw32 (the only available mingw architecture provided by Qt). I just compile my release distributions on MSVC 2015 so I can produce x32 and x64 builds. So to this end, the code base remains quite multi-platform. I'm in the process of setting up an OSX environment but I'd like to stabilize 2.0 before focusing on establishing the MAC port.

The MSVC builds are only release builds to support both x32 and x64 architectures on Windows. I still exclusively develop on mingw maintaining portability code for OSX, Windows, mingw and MSVC as much as possible. For the next LPub3D evolution, I'd like to introduce an OSX distribution but before that I'm focused on stabilizing 2.0.

The main point of my quoted statement above is to say moving to Qt 5.6 (MSVC) / 5.5.1 (MinGW) is better than staying on 4.8 for the reasons highlighted.

The MSVC builds are only release builds to support both x32 and x64 architectures on Windows. I still exclusively develop on mingw maintaining portability code for OSX, Windows, mingw and MSVC as much as possible. For the next LPub3D evolution, I'd like to introduce an OSX distribution but before that I'm focused on stabilizing 2.0.

The main point of my quoted statement above is to say moving to Qt 5.6 (MSVC) / 5.5.1 (MinGW) is better than staying on 4.8 for the reasons highlighted.

Cheers,

Hi Trevor,

I appreciate your input into LPub3D development, which I've been using for some time and find it much better than original LPub.

The message cross-posted by Philo was posted by myself on EB forums (as I was not registered here before). The main concern I wish express is that LPub3D v2.x no longer works in Linux . While it never run natively there is a lovely tool/app/feature many Linux users utilise to run Windows-only programs called "Wine" and it worked just fine for me. Now that you have moved to MSVC2015 it is no longer possible to use newer versions of LPub3D due to complete incompatibility of VC2015 redistributable package with Wine. While it would be awesome to have a cross-platform software that would run natively on Linux I wish to ask for a little favour - making LPub3D at least Wine compatible and not to be tied tightly to Windows OS. Otherwise v1.3.5 is the last version can be used, unfortunately.

The MSVC builds are only release builds to support both x32 and x64 architectures on Windows. I still exclusively develop on mingw maintaining portability code for OSX, Windows, mingw and MSVC as much as possible. For the next LPub3D evolution, I'd like to introduce an OSX distribution but before that I'm focused on stabilizing 2.0.

The main point of my quoted statement above is to say moving to Qt 5.6 (MSVC) / 5.5.1 (MinGW) is better than staying on 4.8 for the reasons highlighted.

Cheers,

Hi Trevor,

I appreciate your input into LPub3D development, which I've been using for some time and find it much better than original LPub.

The message cross-posted by Philo was posted by myself on EB forums (as I was not registered here before). The main concern I wish express is that LPub3D v2.x no longer works in Linux . While it never run natively there is a lovely tool/app/feature many Linux users utilise to run Windows-only programs called "Wine" and it worked just fine for me. Now that you have moved to MSVC2015 it is no longer possible to use newer versions of LPub3D due to complete incompatibility of VC2015 redistributable package with Wine. While it would be awesome to have a cross-platform software that would run natively on Linux I wish to ask for a little favour - making LPub3D at least Wine compatible and not to be tied tightly to Windows OS. Otherwise v1.3.5 is the last version can be used, unfortunately.

Hello Aleksandr - No problem. I can release an x32 version on MinGW. Look for a portable MinGW distribution at LPub3D 2.0.4 which should be out later today.

This application failed to start because it could not find or load the
Qt platform plugin "windows".

Reinstalling the application may fix the problem.

Please note I've been using 64-bit version previously. So if there is anything that had to be installed previously - it is not.

Aleksandr,

This behavior should not be happening under an expected installation approach. Here is what I mean:

You have 2 options to install LPub3D - one by using the NSIS installer-packaged distribution and the other is just to unzip the 'portable' distribution (.zip).

For both cases, you will notice under the root install directory there is a 'plugin' directory called 'platforms' and within that directory there is a 'qwindows.dll'.

If your distribution was successfully installed or unzipped you should no be experiencing the missing plugin behaviour since the plugin is in fact not missing.

If you were previously running the installer-packaged x64 MSVC distribution (of version 2.0.3 let's say), I would recommend a you do a complete uninstall before installing the installer-packaged MinGW distribution. However, you can test the MinGW installation by just unzipping the portable distribution and launching the exe.

Let me know if your are still experiencing this message after following an expected installation approach.

So I've tried both MinGW files - the installer and portable versions and did a bit more of investigation.

Installer executes successfully, however generates error I've mentioned before upon launch. It turns out LPub3D v2.x doesn't like to be launched as Win7 emulated application (worked fine with v1.x though), but doesn't generate the error with WinXP emulatation. Running *.exe file later shows application interface for a second and disappear. Launching app from Windows command line generates the following error:

Portable version has same stuff with Win7/WinXP emulation, but it is not a big issue. However it asks for "Data directory installation folder" to be created outside/inside Program files / (x86)" and fails in both (Yes/No) cases. "No" selection does nothing and simply terminates the application, while "Yes" gives same errors as installable version above.

So I've tried both MinGW files - the installer and portable versions and did a bit more of investigation.

Installer executes successfully, however generates error I've mentioned before upon launch. It turns out LPub3D v2.x doesn't like to be launched as Win7 emulated application (worked fine with v1.x though), but doesn't generate the error with WinXP emulatation. Running *.exe file later shows application interface for a second and disappear. Launching app from Windows command line generates the following error:

Portable version has same stuff with Win7/WinXP emulation, but it is not a big issue. However it asks for "Data directory installation folder" to be created outside/inside Program files / (x86)" and fails in both (Yes/No) cases. "No" selection does nothing and simply terminates the application, while "Yes" gives same errors as installable version above.

Aleksandr - thanks for the detail description of your issues.

I've fixed the "Data directory installation" behavior. Actually, I changed it to be more automated. Look for it in version 2.0.5.

I imagine the qwindows.dll plugin message is linked to the version of Qt i'm using and Wine since the plugin is not missing but cannot be found and the problem is only present on Win7 and not WinXP. I'm not sure what I can do about this but I'll continue to track this issue.

I've attached the qt5svg.dll. Unzip and put it in the root installation folder and let me know if it resolves your dependency messages. In fact, qsvg.dll which is generating this dependency is not required by LPub3D - if your remove it, LPub3D should execute without issues. However, Qt's Windows deployment tool list all 'possible' dependencies and qsvg.dll is one of them so I included it in the distribution to be safe. You can try running your configuration without it and qt5svg.dll.

Looking at the videos in my previous post, you can use the v2.0.4 portable distribution to test the addition/removal of the dlls by following the steps to refresh the user data directory or your can wait for 2.0.5 which will be released sometime today.

Thanks for this update!
And all who installed before who found out some bugs and install / run problems that are now fixed :-)

Here are my findings and verdict:
- The render speed is VERY impressive. Pages load quick!
- Choosing a page size from the various standard is nice
- Love to be able to set local page size

One error:
- When I close LPub3D it crashes. Settings are not saved.

Hello Jaco,

Many thanks for your findings. This release was particularly challenging as I took on switching the platform in addition to a significant redesign to enable the LDView single call render.

I think you may like that it is now possible to freely move callouts on a multi-step page. For me, that was a nice one to do.

Philo also reported the crash on close. This behavior is hard for me to track down as I am on Windows 10 and I have not experienced it - at all. Can you tell me if the crash is consistent, i.e. crashes every time you exit the application or intermittent ? What is your operating system version ?

For the Settings, I deliberately reset the registry to avoid any corruption from settings associated with older versions of LPub3D and this new major version and platform (Qt 5.6 from 4.8 and MSVC versus MinGW release builds). Going forward, configuration settings will not be overwritten.

Sorry i should have precised that I use 64 bits version. And it was not a fresh install but an update from previous version. Dunno if it makes difference...

I was trying to get my hands on an x64 build but I couldn't find it amongst the images MS makes available.

One thing you could try is to backup and then complete delete the registry key for LPub3D Software. Then backup and delete all the user data (...user/appdata/local/LPub3D Software/LPub3D). Install a fresh copy of 2.0.4 - without electing to install user data during installation. Once the installation is finished, launch the application and select copy to setup a fresh copy your user data.

If there are settings your wanted to preserve in your parameter files (annotations etc...), just copy the specific backed up files overwriting the installed versions. For your custom library items, it is recommended to keep these items in your LDraw directory - under the Unofficial directory or in the Models directory. With this configuration, every time LPub3D starts, it will look to integrate any custom items into the LPub3D unofficial library archive file. This way, you can wipe out the LPub3D library archives as you want and not lose your custom content.

If you try this approach, let me know if your crash on end behavior still exist.

Features and enhancements
------------
-Fix: Release Windows MinGW x32 builds (r737)
*Update deployment utiliites to produce both MinGW and MSVC builds. MinGW will only support x32 architecture for the moment.

-Fix: Search directories for LDGlite (LDSEARCHDIRS) not loaded as expected at startup (r735)
*Loading the LDGLite search directories at startup occurred out of order (before general search directories) so the LDGlite routine did not pass the conditional test to actually load search directories. This behaviour would cause a crash if parts to be loaded were in the standard LDraw official or unofficial directories - for example under ..\Unofficial\myParts - and LDrawini was not in use. LDGLite would not be able to find the part and; consequently, would not be able to generate a part image.

-Fix: Fade steps skips the second step in a model. Fading starts on the third step. (r734)
*No fade parts index generated on the first step because nothing was faded; however, we still need an index to know where to start on the second step. Fade step routine fixed to generate an index as long as there are valid parts in the step.

-Fix: Installer program configured to deposit a master copy of user data (libraries, lists, etc...) in the installation root directory. (r733)
*Allow user data creation at initial launch. Upon initial application launch, if user data does not exist, it will be created. This will address the issue of Windows standard users not having access to user data after installation. Additionally, this design allows for multiple users on a single machine to have their individual user settings and data.

-Fix: Set progress dialog to nonmodal. (r732)
*Prevent the progress dialog from blocking input to other windows.

-Fix: Data directory installed under Administrator AppData path instead of logged in user which is likely to be a standard user (r731)
*User data - LDraw archive libraries, logs, extras and other updatable data items - will be installed at initial application launch by default. Because Administrator privileges are required to install LPub3D, user data installed during installation will be deposited under the Administrator user's AppData path. This data will not be accessible to standard users. User data can be installed during application installation as a checked option. This option may be desirable if the logged in user installing LPub3D is also the Administrator. If user data is installed during installation, user data for standard users will be automatically created during initial application launch. On initial application launch, the standard user will be given the options to select, copy (from the installation directory) or download the LDraw archive libraries. (Known Issue: Standard user icons are not being generated at the moment. Also, the uninstall routine will not remove standard user data created at application startup. I'm still working on improving the deployment package to handle these items).

Ok. So, I updated to this new version yesterday and I'm now experiencing something very weird.
Whenever I start the computer, a windows explorer window opens (after Windows login of course) into the folder: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\LPub3D which contains 2 shortcuts to open or uninstall LPub3D.

First off: why does it open?
Secondly: why is LPub3D doing anything after boot anyway? It's not a service or anything

(2016-07-03, 8:03)Merlijn Wissink Wrote: Ok. So, I updated to this new version yesterday and I'm now experiencing something very weird.
Whenever I start the computer, a windows explorer window opens (after Windows login of course) into the folder: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\LPub3D which contains 2 shortcuts to open or uninstall LPub3D.

First off: why does it open?
Secondly: why is LPub3D doing anything after boot anyway? It's not a service or anything

Merlijn,

The icons your see are in your startup folder. This means when you start the computer they will display. LPub3D is not doing anything. The operating system manages the startup behavior - starting (or displaying) whatever is in the startup folder.

You can just remove/move them to where you want if you are not pleased with this behavior. Actually, it was unintentional. I was looking for a solution to install icons for standard users during installation. Normally, the icons should be deposited in the start menu programs. This is where they will continue to be deposited in version 2.0.5.

(2016-07-01, 6:35)Jaco van der Molen Wrote: - When I close LPub3D it crashes. Settings are not saved.

(2016-07-01, 10:15)Trevor Sandy Wrote: I think you may like that it is now possible to freely move callouts on a multi-step page. For me, that was a nice one to do.

Oh, I see now. And the arrows are placed correct too! Great!

(2016-07-01, 10:15)Trevor Sandy Wrote: Philo also reported the crash on close. This behavior is hard for me to track down as I am on Windows 10 and I have not experienced it - at all. Can you tell me if the crash is consistent, i.e. crashes every time you exit the application or intermittent ? What is your operating system version ?

I am on Windows 7 professional sp1 and crash if every time I close LPub3D.

(2016-07-01, 6:35)Jaco van der Molen Wrote: - When I close LPub3D it crashes. Settings are not saved.

(2016-07-01, 10:15)Trevor Sandy Wrote: I think you may like that it is now possible to freely move callouts on a multi-step page. For me, that was a nice one to do.

Oh, I see now. And the arrows are placed correct too! Great!

(2016-07-01, 10:15)Trevor Sandy Wrote: Philo also reported the crash on close. This behavior is hard for me to track down as I am on Windows 10 and I have not experienced it - at all. Can you tell me if the crash is consistent, i.e. crashes every time you exit the application or intermittent ? What is your operating system version ?

I am on Windows 7 professional sp1 and crash if every time I close LPub3D.

Jaco - are you installing under a standard user or user with admin-level access ? What was your previous version of LPub3D ? Thanks.

I am not able to reproduce the crash on launch or crash on exit in my Windows 7 tests but I believe I know what may be causing them in your installation.

Please follow the instructions in this video LPub3D-Win7 Delete RegKey MainWindow and let me know if this helps with the crash on launch. This update is applicable to users updating from earlier versions of LPub3D only.

It could also be helpful to refresh and centralize your user data under the default LPub3D location. This will be done automatically if the existing locations are renamed (then deleted if you desire). You can see this behavior in video LPub3D-Win7 Refresh User Data. Please note that this type of refresh is only available with version 2.0.4 and later. This tip is useful to ensure that standard Windows 7 users are properly configured to run LPub3D.

(2016-07-05, 20:05)Trevor Sandy Wrote: Jaco - are you installing under a standard user or user with admin-level access ? What was your previous version of LPub3D ? Thanks.

Installing as user but have full admin rights.
I can't recall my previous version, but it must have been the latest one before 2.0, since I always updated.
New problem: on my WinXP machine, LPub3D does not start saying LPub3D_x32.exe is not a valid Win32 application.

I don't think I setup my VS2015 IDE to comply with WindowsXP. At any event. I'm sure i'll have to add more dlls to bring the distribution into compatability with XP.
In your opinion, is it necessary to spend time to produce this port ? After all, WindowsXP is very old.
P.S. I was thinking you could try the MinGW distribution. It does not depend on the MSVC runtime which is most likely the cause of your message. Let me know if it works for you on XP ?

I know XP is old, but also know that many machines still run it.
Do I just install MinGW?

(2016-07-05, 20:05)Trevor Sandy Wrote: Jaco - are you installing under a standard user or user with admin-level access ? What was your previous version of LPub3D ? Thanks.

Installing as user but have full admin rights.
I can't recall my previous version, but it must have been the latest one before 2.0, since I always updated.
New problem: on my WinXP machine, LPub3D does not start saying LPub3D_x32.exe is not a valid Win32 application.

I don't think I setup my VS2015 IDE to comply with WindowsXP. At any event. I'm sure i'll have to add more dlls to bring the distribution into compatability with XP.
In your opinion, is it necessary to spend time to produce this port ? After all, WindowsXP is very old.
P.S. I was thinking you could try the MinGW distribution. It does not depend on the MSVC runtime which is most likely the cause of your message. Let me know if it works for you on XP ?

I know XP is old, but also know that many machines still run it.
Do I just install MinGW?

(2016-07-06, 2:44)Trevor Sandy Wrote: Please follow the instructions in this video LPub3D-Win7 Delete RegKey MainWindow and let me know if this helps with the crash on launch. This update is applicable to users updating from earlier versions of LPub3D only.

I do not have the RegKey MainWindow, so cannot delete it.
Updating to 2.0.5 does not help either.
Still crashing after quit on win 7.

(2016-07-06, 2:44)Trevor Sandy Wrote: Please follow the instructions in this video LPub3D-Win7 Delete RegKey MainWindow and let me know if this helps with the crash on launch. This update is applicable to users updating from earlier versions of LPub3D only.

I do not have the RegKey MainWindow, so cannot delete it.
Updating to 2.0.5 does not help either.
Still crashing after quit on win 7.

Ok, Thanks! This issue is quite common (3 people reporting it). I don't understand how come I can't reproduce it on my test environment. Anyway, if you're still experiencing it with the MinGW build, I imagine the only other variable that changed is the version of Qt (to v5.x) so i'll start looking there.

From the dump files i've received, the crash is pointing to ntdll.dll. This means it could be anything but most likely i've written something that throws Qt/Windows out of sync causing a segmentation fault down in the Qt stack somewhere.

It looks like the callout placement relative to the assembly on a multi-step page doesn't work properly. It always aligns to the outside of the assembly, not the insdie. No matter if I choose from the inner square (on the dialog).

So, when I choose Top from the inner square, it actually does to Top:Center from the out square. The same with Right and Right:Center etc. etc.

(2016-07-15, 14:51)Merlijn Wissink Wrote: I've maybe found a bug, but I'm not sure.

It looks like the callout placement relative to the assembly on a multi-step page doesn't work properly. It always aligns to the outside of the assembly, not the insdie. No matter if I choose from the inner square (on the dialog).

So, when I choose Top from the inner square, it actually does to Top:Center from the out square. The same with Right and Right:Center etc. etc.

I haven't tested it very extensive though.

Merlijn,

I couldn't reproduce the behaviour you described.

For me the behaviour is as expected. How is your behaviour different from this video demonstration ?

(2016-07-15, 14:51)Merlijn Wissink Wrote: I've maybe found a bug, but I'm not sure.

It looks like the callout placement relative to the assembly on a multi-step page doesn't work properly. It always aligns to the outside of the assembly, not the insdie. No matter if I choose from the inner square (on the dialog).

So, when I choose Top from the inner square, it actually does to Top:Center from the out square. The same with Right and Right:Center etc. etc.

I haven't tested it very extensive though.

Merlijn,

I couldn't reproduce the behaviour you described.

For me the behaviour is as expected. How is your behaviour different from this video demonstration ?

Cheers,

I did watch your video and now I start to doubt myself though. What exactly is the (intended) difference between the inner square and the outer square on the dialog? Just to be sure.

Sorry for the 'late' reply. I was a bit busy. I'll retry and get back to you tomorrow.

Ok, so I've tested it more and to me it looks like I indeed found a bug.

I thought that the inner square in the 'Placement Dialog' represents the object that you want to place relative to. Most of the time it is the 'Assem' when working with a callout.
So, when I move a callout (relative to the assembly) to Top/Right in the inner square, I expected it to go to the top right of the assembly (so it's on the assembly). When I set it to Top/Right on the outer square, I expected it to go the top-right outside of the assembly (so lining the bottom-left corner of the callout with the top-right corner of the assembly).

As it is now, Top/Right in the inner and outer square do exactly the same, always positioning outside the assembly, but onlyon a multi-step page. When doing the same thing with the same callout on a single step page, it actually behaves differently when selecting Top/Right on the inner square or the outer square (which is correct).

I actually tried this in the old original LPub and it behaves exactly as LPub3D does now, so it's either a very old bug or I'm expecting behavior that I shouldn't expect. What do you think?

Btw, maybe I explained it a bit vague. Just let me know and I'll make a video or something to try explaining it better

(2016-07-18, 9:18)Merlijn Wissink Wrote: Ok, so I've tested it more and to me it looks like I indeed found a bug.

I thought that the inner square in the 'Placement Dialog' represents the object that you want to place relative to. Most of the time it is the 'Assem' when working with a callout.
So, when I move a callout (relative to the assembly) to Top/Right in the inner square, I expected it to go to the top right of the assembly (so it's on the assembly). When I set it to Top/Right on the outer square, I expected it to go the top-right outside of the assembly (so lining the bottom-left corner of the callout with the top-right corner of the assembly).

As it is now, Top/Right in the inner and outer square do exactly the same, always positioning outside the assembly, but onlyon a multi-step page. When doing the same thing with the same callout on a single step page, it actually behaves differently when selecting Top/Right on the inner square or the outer square (which is correct).

I actually tried this in the old original LPub and it behaves exactly as LPub3D does now, so it's either a very old bug or I'm expecting behavior that I shouldn't expect. What do you think?

Btw, maybe I explained it a bit vague. Just let me know and I'll make a video or something to try explaining it better

Merlijn,

For me, the placement behaviour is as expected. Perhaps you should make a video to precise your point.

Indeed, the inner and outer placement commands represent perimeters that you can place your content relative to.

For example, it would not make sense to place content relative to the page using the outer placement commands. On the other hand, it would not make sense to use the inner placement commands to place content relative to the step number. In fact, these examples are strictly controlled and if you select page, the outer commands are disabled. If you select step number, the inner commands are disabled.

For an assem[bly] however, both outer and inner commands are enabled because while most of the time it is likely content will be placed outside the assem border; however, there are times when content may have to be placed inside. An example of placing content inside the assem's border is when a very large assem consumes the entire page so placing a callout would have to use the inner placement commands.

Keep in mind that once the item is placed inside the assem's border the border is recalculated to account for dimensions of the added item.

Ok, so I've made a video to demonstrate the difference between the (imo expected) behaviour on a single step page and the 'wrong' bahaviour on a multi-step page.
If you watch this together with my post above, it might get a little more understandable.

Here's the video. Don't mind the weird text on the right and the resolution. I just made a quick recording and haven't really looked into the settings of the recorder

(2016-07-19, 9:22)Merlijn Wissink Wrote: Ok, so I've made a video to demonstrate the difference between the (imo expected) behaviour on a single step page and the 'wrong' bahaviour on a multi-step page.
If you watch this together with my post above, it might get a little more understandable.

Here's the video. Don't mind the weird text on the right and the resolution. I just made a quick recording and haven't really looked into the settings of the recorder

If you've still got questions, let me know

Jerlijn,

Thanks for making the recording. I'll take a look to see why the different behavior between single and multi-step pages.

You can download the various builds from sourceforge.net or check for updates in your existing installation.

With this build, I believe I have finally addressed the intermittent crash on launch and persistent crash on exit issues particularly present on Windows7 machines. However, as I have not been able to reproduce crash on exit, I'll need those who have to let me know if this behavior continue to exist on their system with this release. For the crash on launch issue I believe this issue was linked to a Qt5 bug because I was able to reproduce it with 2 different code bases and in both bases the problem was resolved with the update to Qt 5.7. Again, I will look to users to confirm that the crash on launch no longer exist. Thanks to all who took the time to provide feedback on these issues.

I've also fixed some interesting items reported by users. Here is the changelog:

LPub3D 2.0.6.761.3

Features and enhancements
------------
-Fix: Set radial and conical background gradient parse fail with 'Malformed background...' (r759)
*Parse fail for radial and conical gradient meta commands. Linear, radial and conical gradients are all now working as designed.

-Fix: Save and restore application window state and geometry (r755)
*Was causing crash on launch before update to Qt5.7.

-Fix: Application crash on launch (r754)
*Update to Qt5.7 on MSVC2015 and MinGW5.3. There must have been a big, nasty bug in Qt 5.5/5.6 because the code that consistently generated the crash immediately resolved upon update to Qt5.7

-Fix: Crash on application close on Windows7 (r753)
*Expected scoped pointer main window to destruct all children on close but it seems like 3d viewer application and mainwindow were not treated as children and were not deleted at application close by the scoped pointer on Windows7 machines. Manually delete 3D viewer application instance and mainwindow at LPub3D termination.

-Fix: Substitute parts use only file name; file path not required (r752)
*When editing substitute parts list, it is not necessary to enter the absolute file path for the substitute file. Just entering the substitute file name will be sufficient.

-Fix: Title annotations displays when only Freeform annotation selected in setup preference (r751)
*Logic processed title annotations when it should not have. Corrected.

-Fix: setGeometry: Unable to set geometry 600x800 warning message (r749)
*Use QDesktopWidget.availableGeometry(this) setting to support single and multi-screen configurations.

-Fix: Parameter file edit window highlighting part description containing '#' (r748)
*Highlight only lines where first character is '#'.

-Fix: Generate fade colour parts list crash (r747)
*Redesigned functionality to process parts from archive libraries (unofficial and official) versus LDraw disc directories. This approach improves performance and reliability as all parts, including those from additional search directories, are collected in the archive libraries. Working with archive files is much faster than working with disc directories.

You can download from sourceforge.net or check for updates in your existing installation.

Features and enhancements
------------
-Fix: Elapsed timer on file open (r771)
*Display elapsed time to load a file.

-Fix: Archive library copy function not working if [empty] library directoy exist (r770)
*If user data libraries directory exist, library copy from installed base is ignored. This is an issue if there are no libraries in the library directory. The correct behaviour is to verify that libraries exist and copy if they don't.

-Fix: Inconsistent fade behaviour when using BUFEXCHG parts and added parts in the same step (r764)
*Behaviour previously used the size of the previous step's CSI to determine the fade position index of the current step in all cases. This approach could lead to an inconsistent fade position after retrieving a buffer. Behaviour corrected to use the size of the previous buffer parts list (versus the CSI) to determine the current step's fade position when BUFEXCHG RETRIEVE meta command is used. This approach removes the necessity to follow the BUFEXCHG RETRIEVE meta command with a STEP/ROTSTEP meta command to process the fade sequence which will unnecessarily render the buffered items twice, in the buffered view and the modelled view. Usually only the buffered view render is desired in the current step (that's why the assembly is buffered in the first place) but the modelled view CSI should be carried forward to the next step. Here are two examples:

Example 1: No unbuffered parts in step 1, render buffered skeleton with arrow in step 1 but render only modelled skeleton faded and the current parts in step 2

LPub will display 4 bricks for the 2nd step. But (imho) it should exclude 3005pe5.dat

I'm not sure about this though, I ran into this when validating the new LDCad 1.6 bufexchg stuff.

Yep - I agree. The PLI should display 3005pt3.dat, 3005pt4.dat and 3005pt5.dat.

I'll take a look.

Cheers,

Roland, I took a look. Basically the issue is if you call BUFEXCHG RETRIEVE after inserting parts in the step, those parts will be overwritten with parts from the buffer.

So here is what happens with each meta command:
0 BUFEXCHG A STORE: put all parts in the step up to the pont of the command into a buffer.
0 BUFEXCHG A RETRIEVE: overwrite the current parts list (csiParts) with the parts from the buffer.
If I use your sample:

We can expect for step one three parts will be in the CSI and PLI (3005pt1.dat, 3005pt2.dat and 3005pe5.dat). Two parts are stored in the buffer (3005pt1.dat and 3005pt2.dat)

For step 2 we can see the parts from the buffer have been retrieved in the CSI (3005pt1.dat and 3005pt2.dat); however, they correctly do not show in the PLI. We can also correctly see step 2's parts in the PLI (3005pe5.dat, 3005pt3.dat, 3005pt4.dat and 3005pt5.dat) but part 3005pe5.dat is not displayed in the CSI.

That part 3005pe5.dat is missing from the CSI, I believe, is the problem in your example. As stated earlier, this behaviour is because retrieving the buffer overwrites any parts in the CSI list so because BUFEXCHG A RETRIEVE in your example is after the declaration of part 3005pe5.dat; we see this part in the PLI but it is not in the CSI image.

If we move BUFEXCHG A RETRIEVE to be the first declaration in step two. The behavior is as designed.

I could include logic to check if any parts are declared in the step before the BUFEXCHG A RETRIEVE command but this could get complicated if multiple buffer commands are declared within a step. I think it is ok to just advise that, in a step, one should declare the BUFEXCHG A RETRIEVE first or before any parts are declared.

(2016-08-03, 4:18)Trevor Sandy Wrote: I could include logic to check if any parts are declared in the step before the BUFEXCHG A RETRIEVE command but this could get complicated if multiple buffer commands are declared within a step. I think it is ok to just advise that, in a step, one should declare the BUFEXCHG A RETRIEVE first or before any parts are declared.

What do you think?

Cheers,

I know this is not very common usage, I was just trying weird things to test my implementation.

So you could make it a 'known limitation' as it won't be used in that way often anyway.

While implementing this stuff for LDCad I did realize the main trick in processing the BUFEXCHG metas is to loop trough the model's lines BACKWARDS, that way it won't matter how many buffers are nested even if you would be using more then just A-Z ones This might be helpful for LPub too.

(2016-08-03, 4:18)Trevor Sandy Wrote: I could include logic to check if any parts are declared in the step before the BUFEXCHG A RETRIEVE command but this could get complicated if multiple buffer commands are declared within a step. I think it is ok to just advise that, in a step, one should declare the BUFEXCHG A RETRIEVE first or before any parts are declared.

What do you think?

Cheers,

I know this is not very common usage, I was just trying weird things to test my implementation.

So you could make it a 'known limitation' as it won't be used in that way often anyway.

While implementing this stuff for LDCad I did realize the main trick in processing the BUFEXCHG metas is to loop trough the model's lines BACKWARDS, that way it won't matter how many buffers are nested even if you would be using more then just A-Z ones This might be helpful for LPub too.

That's right. When combined with the exponential amount of scenarios that can present with so many meta commands, it can be a bit challenging to know if you have covered all possibilities when you add to or change the current behaviour. It would not be big deal to read the step backward from the BUFEXCHG meta to identify any declared parts. It's just a matter of reading backward until either you hit a BUFEXCHG STORE or a STEP.

On another topic. Today I successfully compiled Qt 5.7 on MinGW 6.1 x64 using the MSYS2 PKGBUILD framework. The build setup process was quite efficient but took 6 hours to complete. LPub3D builds without issue on this platform so now I've only to update the deployment scripts and I'll be back to 100% MinGW. I'm so happy to get away from MSVC .

(2016-08-03, 22:47)Trevor Sandy Wrote: That's right. When combined with the exponential amount of scenarios that can present with so many meta commands, it can be a bit challenging to know if you have covered all possibilities when you add to or change the current behaviour. It would not be big deal to read the step backward from the BUFEXCHG meta to identify any declared parts. It's just a matter of reading backward until either you hit a BUFEXCHG STORE or a STEP.

On another topic. Today I successfully compiled Qt 5.7 on MinGW 6.1 x64 using the MSYS2 PKGBUILD framework. The build setup process was quite efficient but took 6 hours to complete. LPub3D builds without issue on this platform so now I've only to update the deployment scripts and I'll be back to 100% MinGW. I'm so happy to get away from MSVC .

Cheers,

Yes all those metas can be quite a pain when combined

mingw54/MSys2 is indeed a nice platform I'm using it for LDCad too. For me the most time went into choosing a threading/exception model. After that wxWidgets compiles in about 10 minutes (-j8) or so.

(2016-08-03, 23:15)Roland Melkert Wrote: mingw54/MSys2 is indeed a nice platform I'm using it for LDCad too. For me the most time went into choosing a threading/exception model. After that wxWidgets compiles in about 10 minutes (-j8) or so.

I've personally found the free Microsoft compilers to be pretty good over the years (especially more recently with C++), so I'm curious why you both feel that MinGW does a better job. Note: this post isn't intended to be at all negative: I'm honestly curious. Is it because of the 3rd-party toolkits you're using (Qt and wxWidgets)? Or is it so that you can use the same compiler on both Windows and Linux?

I feel that the fact that LDView gets compiled on three completely different compilers (VC on Windows, gcc on Linux, and Clang on Mac) improves its code, because each compiler contributes warning messages that the others don't.

(2016-08-04, 5:06)Travis Cobbs Wrote: I've personally found the free Microsoft compilers to be pretty good over the years (especially more recently with C++), so I'm curious why you both feel that MinGW does a better job. Note: this post isn't intended to be at all negative: I'm honestly curious. Is it because of the 3rd-party toolkits you're using (Qt and wxWidgets)? Or is it so that you can use the same compiler on both Windows and Linux?

I feel that the fact that LDView gets compiled on three completely different compilers (VC on Windows, gcc on Linux, and Clang on Mac) improves its code, because each compiler contributes warning messages that the others don't.

When I started with LDCad is was looking for a seamless solution for developing multi platform, GCC seemed the only logical way to go as it is available almost everywhere. Also the msys/mingw stuff makes the building environment very Linux like so not only code will be portable but the makefile etc too.

Being mainly a Delphi developer at the time I also wanted to have a minimal amount of dll dependencies as deploying is just so much easier that way.

It was quite a step back IDE wide though, but on the upside GDB integration with code::blocks is improving all the time.

(2016-08-04, 17:31)Roland Melker Wrote: Being mainly a Delphi developer at the time I also wanted to have a minimal amount of dll dependencies as deploying is just so much easier that way.

FYI, contrary to popular belief, Microsoft's compiler can be used without DLL dependencies. In fact, LDView does so, which makes the LDView executable file larger, but avoids problems that people run into otherwise. (Yes, LDView depends on Windows DLLs, but all Windows programs depend on Windows DLLs.)

(2016-08-03, 23:15)Roland Melkert Wrote: mingw54/MSys2 is indeed a nice platform I'm using it for LDCad too. For me the most time went into choosing a threading/exception model. After that wxWidgets compiles in about 10 minutes (-j8) or so.

I've personally found the free Microsoft compilers to be pretty good over the years (especially more recently with C++), so I'm curious why you both feel that MinGW does a better job. Note: this post isn't intended to be at all negative: I'm honestly curious. Is it because of the 3rd-party toolkits you're using (Qt and wxWidgets)? Or is it so that you can use the same compiler on both Windows and Linux?

I feel that the fact that LDView gets compiled on three completely different compilers (VC on Windows, gcc on Linux, and Clang on Mac) improves its code, because each compiler contributes warning messages that the others don't.

For me it is mostly because of the history of the LPub3D codebase. LPub3D appear to do better under MinGW. I imagine because the original LPub4 base was not a MSVC port. Also, some of the additional open source components I've added to create LPub3D were not MSVC compliant - notably LDrawini and Quazip.

However, probably the biggest turn-off is Microsoft's culture of 'bloat,' dependencies and uni-platform architecture. Despite their efforts to combat these items recently, they are still quite persistent in desktop development.

You can download from sourceforge.net or check for updates in your existing installation.

This release reverts to MinGW distributions for both x86 and x64 architectures. I will not produce MSVC distributions going forward.

Features and enhancements
------------

-Fix: Print/export 'page range' option output incorrect (r785)

*For print/export option "All pages," images are generated in numerical order. However, for option "Page Range," images are generated in "alphabetical" order for lack of a better description. If one selects pages 1-115, the order the pages are generated is 1, 10, 100, 11, 12, 13, 14, 15, 16, 17, 18, 19, 2, 20... The order is now as expected 1...10...100 etc...

-Fix: Refactor loading model file into Ldraw editor window (r783)
*File load hangs for an unusual amount of time when loading a large model file. This behaviour appears usually when the LDraw editor tab is not in focus. If the file is loaded with the editor tab in focus, the file is loaded nominally.

-Fix: Backup parameter files during install (r778)
*Backup user-editable parameter files that must be overwritten during installation of updates. This way, any additions created by the user will not be lost. However, it will be necessary to manually update the new parameter file with your additions.

-Fix: Adjustable renderer process timeout (r776)
*All the user to manage the amount of time to keep alive the renderer process. The default is 6 minutes but can be changed between -1 which is run indefinitely and 99 minutes. For high definition using POV-Ray, rendering process time can easily exceed the default. This setting is located at Preferences/Rendering/Process timeout.

-Fix: Reload archive libraries into memory (r775)
*On model file load, do not reload library if no new parts discovered. LPub3D sweeps the defined search directories upon file load. This update makes a little more efficient the load process.

-Fix: Update aboutdialog display version of Qt (r774)
*Display version of Qt from the platform versus hard coded.

Trevor would it be interesting if I added substitute information to LDCad's generated content. That way LPub3D could do auto substituting without the user having to surround the generated part with pli meta's.

I could add something to the 'GENERATED' meta, maybe something like...

(2016-08-10, 18:22)Roland Melkert Wrote: Trevor would it be interesting if I added substitute information to LDCad's generated content. That way LPub3D could do auto substituting without the user having to surround the generated part with pli meta's.

I could add something to the 'GENERATED' meta, maybe something like...

Roland - This would be a good attribute to add especially if the user also has the ability to set it from the template GUI. This way, the user would have the ability to choose whatever representation s/he wanted to display in the PLI.

In LPub3D, as you said, the advantage is the ability to fully automate the substitution process. A disadvantage would be to not have the ability to choose your substitute representation. However, I can work around this by first checking for entries in the substitute list then the LPub meta and finally LDCad.

Trevor, if you're looking for feature suggestions, I have a nice one that surfaced on eurobricks.com.

Sometimes a model uses the same submodel multiple times, but not all in the same step. However, LPub always displays the submodel/callout for the total amount that it's being used in the model.

An example: when a model has 4x the same submodel, but 2 of those are used in step 10 and the other 2 are used in step 20, LPub will create 1x the submodel building steps with a 4x next to it.

The usual workaround is to copy the submodel and give it another name. It would be way easier though, if LPub would automatically count how many times a submodel is used in a certain step and adjust the (using the above example) 4x to 2x and generating a second submodel building steps at step 20.

Well, if that sounds kinda vague, probably my problem. I'm not too good at explaining things...

(2016-08-15, 6:52)Merlijn Wissink Wrote: Trevor, if you're looking for feature suggestions, I have a nice one that surfaced on eurobricks.com.

Sometimes a model uses the same submodel multiple times, but not all in the same step. However, LPub always displays the submodel/callout for the total amount that it's being used in the model.

An example: when a model has 4x the same submodel, but 2 of those are used in step 10 and the other 2 are used in step 20, LPub will create 1x the submodel building steps with a 4x next to it.

The usual workaround is to copy the submodel and give it another name. It would be way easier though, if LPub would automatically count how many times a submodel is used in a certain step and adjust the (using the above example) 4x to 2x and generating a second submodel building steps at step 20.

Well, if that sounds kinda vague, probably my problem. I'm not too good at explaining things...

(2016-08-15, 6:52)Merlijn Wissink Wrote: Sometimes a model uses the same submodel multiple times, but not all in the same step. However, LPub always displays the submodel/callout for the total amount that it's being used in the model.

Merlijn - I have updated LPub3D behaviour to display the submodel instance count reflecting only the number of instances used in the parent step. However, note that there is an efficiency tradeoff to this change in the form of more redundant steps in your instructions.

For example, if I have 4 occurrences of a submodel in a 3-step model file and I consume 2 in step 1 and 1 each in steps 2 and 2, under the previous behaviour, you would indeed see 4 occurrences of the submodel on its last page - displayed while in parent step 1. The efficiency here is that for step 3 and 3 you will not again enter into the sub model's page(s) on the instructions because all 4 occurrences were already communicated to the user. LPub3D handles this by designating the submodel as being 'rendered' at the first occurrence for the entire model file.

For the new behaviour, the submodel is designated as 'rendered' at the first occurrence only for the step in which it is consumed. So subsequent occurrences in the same step will not enter into the submodel page(s). With the new behaviour, as LPub3D would only communicate 2 occurrences consumed in step 1, it will now be necessary to enter into the submodel page(s) on each step a submodel is consumed. This behaviour will not only communicate the remaining occurrences but it will also compel the user to navigate again and again the submodel's page(s).

For small models this may not be an issue but for large models or models where a submodel is large and used in many steps, the instructions will be overwhelmed with redundant information.

To balance this tradeoff, I have added an option switch under Project Setup to enable or disable the consolidation of submodel occurrences at the first occurrence of the submodel (by parent model of course) in the instructions.

Yes, I understand. Maybe it's possible to automatically keep using the old way of rendering submodels just once and add a new LPUB meta command that tells the specific parent step to force render the submodels? No idea if that's possible/lot of work.

(2016-09-15, 6:49)Merlijn Wissink Wrote: Yes, I understand. Maybe it's possible to automatically keep using the old way of rendering submodels just once and add a new LPUB meta command that tells the specific parent step to force render the submodels?

You can download the various builds from sourceforge.net or check for updates in your existing installation.

The key update in this release is moving the fade parts folder from the ldraw/unofficial directory to the LPub3D user data directory. I made this change avoid write access issues when ldraw is installed under a different user appdata than LPub3D, or ldraw is installed in Program Files (x86). This change particularly target environments running LDraw AIOI where the ldraw library is installed under the public Windows user. From this release, all LPub3D updateable content will be located under the LPub3D user data location. Please note that for portable distributions, this location is the LPub3D root folder. For installed distributions, the user data defaults to <Drive>\Users\<User>\AppData\Local\...

LPub3D 2.0.9.792.2

Features and enhancements
------------
-Fix: Align 3Dviewer and rendered csi image rotation (r791)
*The model loaded in the 3D viewer and its corresponding csi step image are now similarly rotated.

-Change: Move fade part files folder to lpub3d data directory - was previously under ldraw/unofficial directory (r790)
*Remove potential conflict when ldraw disc library is located under Program Files(x86) or a user data directory which is different from the user LPub3D is installed under. For example, LPub3D may be installed under standard user 'foo' while the ldraw disc library is installed under user 'public' [or under Program Files (x86). In both cases, LPub3D will likely be blocked from creating fade part files under the ldraw directory - i.e. in Unofficial/fade. Moving the fade folders will ensure write access is always available as the fade part files folder will be under the LPub3D data directory (e.g. C:\Users\foo\AppData\Local\LPub3D Software\LPub3D\fade) Note: If you are using an ldraw.ini configuration file which include paths to the fade/parts and fade/p folders, you must update the paths accordingly. You must also update the extra search directories dialog in LDView if you are using it as your renderer.
Here is an example of what the new paths should look like if you are running an installed distribution:
C:\Users\[userid]\AppData\Local\LPub3D Software\LPub3D\fade\p
C:\Users\[userid]\AppData\Local\LPub3D Software\LPub3D\fade\parts

-Fix: Move cache to root install folder for portable distributions (r788)
*Allow all runtime components of portable distribution to be contained within the folder structure of the distribution.

-Fix: Extract archive library after download (r787) *After archive library download, extract contents to defined LDraw disc library location. Archive libraries can be downloaded at application launch if no archive was found and at the tools menu where one can 'Refresh' the libraries at any time. The aim of this enhancement is to synchronize and automatically update both the archive and disc LDraw library content.

Some further investigation implies it may be something to do with LDView not having visibility of the path to the faded part.
I opened the "csi.ldr" file within the LPub3d/tmp folder using a text editor and could see the three parts for the last step on the first page. I then opened the "csi.ldr" file using LDView, which yielded the first screenshot shown below. Using the LDView menu option "File/Extra Dirs ...", I then added the path "D:\users\Vista\djm\AppData\Local\LPub3D Software\LPub3D\fade\parts" within LDView, reloaded the file in LDView which yielded the second image shown below. The second screenshot is what I expected LDPub3D would have generated.

Note that even though LDView now has the extra directory explicitly added, it does not appear to be using it when invoked by LPub3D.

2016-09-06, 8:46 (This post was last modified: 2016-09-06, 8:51 by David Manley.)

Some further diagnosis/thoughts/questions.

It turns out that I had my preferred renderer set to "LDGLite" rather than LDView (menu item "Configuration/Preferences", tabbed sheet "Rendering", drop-down list "Preferred renderer:"). Once I set it to LDView, exited and restarted LPub3D, it began to include the faded motor as desired. Additional diagnosis showed that this was because I had manually added the directory path "D:\users\Vista\djm\AppData\Local\LPub3D Software\LPub3D\fade\parts" via the LDView menu option "File/Extra Dirs ...".

A quick experiment using the command line to invoke LDView showed me that by using the command line argument "-extrasearchdirs/dir001=", I can pass the necessary directory path to LDView and it will generate the faded motor.

So, my thoughts and questions are as follows;1) could LPub3D, when invoking LDView, use the ""-extrasearchdirs" to pass the directories required for the faded parts?2) should LPub3D generate the instructions including the faded motor when using LDGLite as the renderer or is this a known shortcoming from using LDGLite as the renderer?

Regards,

David

P.S. I'm still finding the modal window displayed when generating a PDF is problematic but I'll post separately on this another time.

P.P.S. edited to include image showing the test build with the desired faded motor.

(2016-09-06, 4:56)David Manley Wrote: 1) could LPub3D, when invoking LDView, use the ""-extrasearchdirs" to pass the directories required for the faded parts?2) should LPub3D generate the instructions including the faded motor when using LDGLite as the renderer or is this a known shortcoming from using

Regards,

David

I just read your last post.

I have been working with Travis to extend the capabilities of LDView. Searching the extra search directories, defined through the LDView GUI, from a command call is one of the updates available to me but not yet released publicly I believe. Sorry, I completely forgot about this when I merged that enhancement to production. From your last post, it looks like you are able to invoke the extra search directories defined from the LDView GUI via LPub3D command call using LDView 4.2. For me, calls on Window 10, did not succeed to use the GUI defined extra search directories; hence the updated version of LDView (4.3) I am currently working with.

To Answer your questions:

From LPub3D 2.1, LDView will be included in the distribution as a 3rd-party renderer as is currently the case for L3P and Ldglite. All required search directories will be automatically communicated between LPub3D and the 3rd Party renderers.

Yes, LPub3D should generate the instructions including the faded motor when using LDGLite as the renderer. This is working as expected on my environment with and without ldrawini. Be sure your are using the latest version of LDGlite or that your preferences are mapped to the version distributed with LPub3D. The LPub3D version can be found at C:\Program Files [(x86)]\LPub3D\3rdParty\ldglite1.3.1_2g2x_Win\ldglite.exe

(2016-09-06, 8:52)Trevor Sandy Wrote: Yes, LPub3D should generate the instructions including the faded motor when using LDGLite as the renderer. This is working as expected on my environment with and without ldrawini. Be sure your are using the latest version of LDGlite or that your preferences are mapped to the version distributed with LPub3D. The LPub3D version can be found at C:\Program Files [(x86)]\LPub3D\3rdParty\ldglite1.3.1_2g2x_Win\ldglite.exe

I'll take a look at your log and example.

Trevor,

I checked which LDGLite I had LPub3D pointing to and it was one I had installed previously when I installed the LDraw suite. So I amended the configuration and instead pointed it at the one distributed with LPub3D (per your post).

Sadly, the rendered instructions do not include the faded motor. I have attached the LPub3D log file to this post to assist with diagnosis.

(2016-09-06, 10:17)David Manley Wrote: Sadly, the rendered instructions do not include the faded motor. I have attached the LPub3D log file to this post to assist with diagnosis.

I can't reproduce your behaviour. For me all is working as expected.

- Did you clear your model cache (the generated LPub3D folder at the root of your model) so a fresh CSI image can be rendered ?
- Your log looks strange. It shows PLI files being generated but no CSI are generated - e.g. the motor and motor with pins. It should show either all (CSI, PLI) being generated or none being generated (i.e. already created). Are you manually manipulating the CSI/PLI images ?

As Trevor mentioned, there is a bug in LDView, which is that it doesn't remember the directories you add to the extra search dirs. They work until LDView is relaunched. Of course, LPub3D launches LDView, so they never work. As you discovered, this can be dealt with on the command line (although doing so would prevent the first entry made in LDView from working in the future when that is fixed).

You can download the various builds from sourceforge.net or check for updates in your existing installation.

This fix will automatically add LPub3D fade parts directories to the extra search directory list if they exist and are not empty. Note If you apply this update over an existing installation where ldrawini is not enabled, LPub3D will read the extra search directories list from the registry setting. To update the extra search directory list with the additional directories that this fix may add, use the 'reset' function in Preferences/Other/LDraw Content Search Directories. The reset function will read all default extra search directories from disc.

Change Log:

LPub3D 2.0.10.793.2

Features and enhancements
------------
Fix: Search directories not added to LDSEARCHDIRS env variable (r793) *LDSEARCHDIRS is used by LDGlite to process LPub3D extra search directories.

2016-09-07, 23:54 (This post was last modified: 2016-09-07, 23:55 by David Manley.)

(2016-09-07, 22:16)Trevor Sandy Wrote: LPub3D 2.0.10 is released.

You can download the various builds from sourceforge.net or check for updates in your existing installation.

This fix will automatically add LPub3D fade parts directories to the extra search directory list if they exist and are not empty.

Thank you Trevor. I have tested and confirmed that this release renders the faded motor using LDGLite as desired. I would like to emphasis something Trevor stated in his post. Namely to "use the 'reset' function in Preferences/Other/LDraw Content Search Directories". Once you have done this, you may need to exit from LPub3D one time and restart it again in order to get LDGLite to pick up the modified search directory list.

You can download from sourceforge.net or check for updates in your existing installation.

This release include fixes which are more like enhancements. Anyhow, notable fixes are:

- Print/Export mixed size and orientation pages. Preview pdf export all pages, current page or page range.
- Optionally display the submodel count occurring within the current step - default behaviour will show the submodel count for the entire current submodel.
- Part count on model load

Change log:

LPub3D 2.0.11.816.2

Features and enhancements
------------
Fix: Close model file (r810)
* Close model file and release all resources.

Fix: Page size display in Page Setup dialogue does not show accurate size (r808)
* Conversion rounding error (between inches and centimetres) preventing the right page size index from being identified. Redesign to use single source (inches) converted dynamically between inches and centimetres when needed.

Fix: Reload at file change prompt (r807)
* Users are now prompted to reload the model file when the loaded file is changed by an external source. With this fix, one can model the same file with multiple applications at the same time.

Fix: Configuration parameters editor extra prompt to save before close (r807)
* LPub3D configuration file editor prompting to save changed content at the both the editor's window close and LPub3D main window close. This behaviour has been corrected to prompt only at editor window close.

Fix: Part count gives wrong result. (r806)
* Setting an automatic piece count gives wrong count most of the time in an MPD with multiple submodels and multiple usages of certain same submodels. This behaviour is now corrected. However,the user will have to play a role in configuring her model file to accurately reflect the part count expected. This will undoubtedly require moderate knowledge of LDraw and LPub3D format/logic semantics. The implemented part count capabilities will aim to minimize the intervention of the user but; ultimately, the strength of the part count will depend on the integrity of the model file.
In LPub3D, three configuration patterns will determine if a part is counted:
1. The part file must contain a well formed part type meta.
Examples: 0 !LDRAW_ORG Part, 0 LDRAW_ORG unofficial_part, 0 LDRAW_ORG unofficial part, 0 unofficial part
Note that LPub3D does not look at the file extension to distinguish between types. Therefore, one could have a file named foo.mpd which will be identified as a part if the above meta declaration exist. Conversely, if no declaration is present, foo.dat or foo.ldr will not be identified as a part. This feature can be useful when defining helper parts. For example, leaving out the type declaration in the file uparrow.dat will allow the user to include it in their instructions with out it being counted as a part.
2. Using the IGN (ignore) LPub meta will automatically exclude the part lines within from being counted.
For example:

Note that parts in model subfiles within the IGN declaration will also be ignored - like outerrib.ldr above.
3. There is now a part exclusion list under the user data directory ...extras/excludedParts.lst.
As with the other LPub3D lists, the part exclusion list can be edited from the configuration menu.
The exclusion list is effective in the scenario where one is using dynamically generated parts such as hoses, string, rope etc... Segment parts, e.g. LSynth's LSXX.dat parts, stickers, LDCad template segments etc... can be excluded from the part count by placing them on the exclusion list.

Fix: Submodel instance count reflects all the occurrences in the subfile on initial display (r805)
* An example: when a model has 4x the same submodel, but 2 of those are used in step 10 and the other 2 are used in step 20, LPub3D will create 1x the submodel building steps with a 4x next to it.
LPub3D behaviour will now, optionally, display the submodel instance count reflecting only the number of instances used in the parent step. However, note that there is an efficiency trade-off to this change in the form of more redundant steps in your instructions.
For example, if I have 4 occurrences of a submodel in a 3-step model file and I consume 2 in step 1 and 1 each in steps 2 and 2, under the previous behaviour, you would indeed see 4 occurrences of the submodel on its last page - displayed while in parent step 1. The efficiency here is that for step 3 and 3 you will not again enter into the sub model's page(s) on the instructions because all 4 occurrences were already communicated to the user. LPub3D handles this by designating the submodel as being 'rendered' at the first occurrence for the entire model file.
For the new behaviour, the submodel is designated as 'rendered' at the first occurrence only for the step in which it is consumed. So subsequent occurrences in the same step will not enter into the submodel page(s). With the new behaviour, as LPub3D would only communicate 2 occurrences consumed in step 1, it will now be necessary to enter into the submodel page(s) on each step a submodel is consumed. This behaviour will not only communicate the remaining occurrences but it will also compel the user to navigate again and again the submodel's page(s).
For small models this may not be an issue but for large models or models where a submodel is large and used in many steps, the instructions will be overwhelmed with redundant information.
To balance this trade-off, I have added an option switch under Project Setup to enable or disable the consolidation of submodel occurrences at the first occurrence of the submodel (by parent model of course) in the instructions.

Fix: Pdf preview progress bar (r803)
* Add progress bar to pdf preview dialogue. For large instruction documents it could be good to monitor the progress of the export process.

Fix: Front and back cover page attribute placement (r802)
* By default cover page attributes are placed relative to each other (with one anchor placed relative to the page) on the front and back cover pages. Independent page attributes are by default placed relative to the page. The new behaviour will break the dependency (placing the dependent attribute relative to the page) if the attribute depended upon is not respecting it's default placement relation (i.e. its relation has changed to page). I imagine this is more complex that it probably should be but the aim was to automatically place the attributes on model load so young/novice users would not have to fuss with even more complex configuration.
The quirk remaining is when you change placement relative on an attribute depended upon by another, the dependent attributes will obviously follow the position of the newly placed attribute. This may confuse users as it can be perceived as a bug. There are two ways around this when repositioning cover page attributes. One is to not change placement relation but use the drag functionality and; two, from thee bottom-up, set dependent attributes placement relation to page.
All attributes are optionally viewable. If a depended upon attribute is not visible, its dependant attribute is automatically placed relative to the page.
Here is the the placement relation table - any attribute not placed relative to the page is dependent:

Fix: Mixed page size and orientation export - pdf, png etc... (r801)
* The feature to set local page orientation works on screen, but not in the output in PDF or PNG. One is now able to successfully change both page size and orientation locally (at individual page). This capability applies to both pdf and image exports.
Additionally, there is now the [experimental] capability to preview your pdf output using the pdf preview menu item. Note that the preview dialogue uses the Qt native print engine (with pdf format output) to support print preview so mixed page size and orientation within the preview document is not well supported. For the moment, mixed page size and orientation documents will preview using the only the original page size and orientation. Output will be cropped and formatted accordingly. If your document does not contain mixed page size or orientation then the print preview functionality should present as expected. Also, note that printing usually consumes quite a bit of memory so, at this time, printing very large graphic intensive documents may experience abnormal termination.
Previously, LPub£D was using the default print engine (with pdf format output) which functions just as a physical printer. This means that as no one is likely to physically print different size pages during the same print run (at least not in standard printing), the pdf printer seemed unhappy when you try to switch page size while the printer is active. LPub3D now uses Qt's pdfWriter. Switching to the pdfWriter engine removes the limitation on both size and orientation while the 'printer' is active.

Fix: Submodel instance count placement broken (r800)
*When using page number in alternate corners (like a book) the Submodel instance count is at the wrong place when it is on a odd page number on a single page submodel with a step group. Behaviour corrected and enhanced to detect when submodel instance count is on an odd or even page whereby the position is adjusted right or left of the step number accordingly. This automatic positioning is only available when the submodel instance count is placed relative to the page's step number - its default placement.

You can download from sourceforge.net or check for updates in your existing installation.

LPub3D 2.0.12.823.2

Features and enhancements
------------
Fix: LDView SnapshotSuffix to persist .png image generation (r820)
* As designed, LDView will use the last "Save as type" parameter set in the Save Snapshot dialogue for command line exports. I've added the command parameter -SnapshotSuffix=.png to force png image output in situation the user changes the LDView save as type from .png (e.g. exports a snapshot in .jpg format) while working outside of LPub3D.

Known Issue: Some JPEG-compressed images types are not rendered as inserted image (r818)
* This was a Qt bug claimed to be corrected in Qt 5.5.1 (LPub3D uses 5.7); however, the issue seem to persist in Qt 5.7 also. Not all jpg images fail to load. The issue appear to be related to JPeGs with broken EXIF headers only.

You can download from sourceforge.net or check for updates in your existing installation.

Interesting fixes are the ability to switch part occurrence (times used) in the PLI between per step and per submodel on called out and submodel pages; the ability to insert one-to-many non-faded models (e.g. with alternate attachments/views etc...) when fade step is on; and new meta for pages size including the standard identifier - e.g. A4, Letter, Legal etc... and print/export performance improvements.

Fix: Inconsistency between part counts in submodels and part counts in call-outs where multiple instances are involved (r829)
* For submodels, the PLI part counts reflect only one instance of the submodel, even if multiple instances are used in the same step. The instance count is correct, and the BOM has the correct total number of parts. With this update, sub-model pages displaying instance count now have a context menu option to display parts per step/page or not (total parts consumed by the number of instances indicated.
Previously, for callouts, you have the options (see context menu) to display parts list per callout (one instance) or not. When you select no parts list per callout, the PLI will show all the parts consumed by the total number of instances in the callout. If you choose parts list per callout, the PLI is moved to the callout and only the parts for a single occurrence of the callout is shown. The idea here is if you have 5 occurrences of the called out assembly, you'll need 5x the parts total, but only 1x parts are shown to indicate what you need to build an instance of the called out assembly.
On sub-model pages displaying the instance count, there is only one behaviour for PLI counts (the most intuitive) which is to display the parts list per step. This is intuitive because the primary role of the PLI is to show what you'll need to build an occurrence of the step shown - it is not the intention to mimic the BoM. Nevertheless, I added a context menu item to not display parts list per step and instead display total parts consumed by the number of occurrences of the submodel in the parent submodel/step.

Fix: Page size and orientation processing update (r826/833)
* Further industrialization of the print/export module. This update streamlines the process and realizes some performance gains. There are some key changes. Notably, page orientation and page size are now mutually exclusive. This means when switching from Portrait to Landscape, accompanying the orientation meta with a transposed page size meta no longer required or managed. Here is an illustration:
Previous behaviour when editing a page size change required the following meta commands:
0 STEP
0 LPUB PAGE ORIENTATION LOCAL LANDSCAPE
0 LPUB PAGE SIZE LOCAL 11.0000 8.5000
Note that the page width and height have been transposed. Going forward, transposition of the page width and height when switching from Portrait to Landscape is automatically managed by LPub3D.
NOTE: This update is NOT backward compatable. An accompanying transposed page size meta to indicate the switch from portrait to landscape as shown above will be treated as a new page size meta for that page. Consequently, using this meta to 'switch' orientation will actually result in NOT switching the orientation as LPub3D will automatically switch again the switched page size meta.
If the user is only interested in changing the orientation, the proper meta command going forward will be:
0 STEP
0 LPUB PAGE ORIENTATION LOCAL LANDSCAPE
To help with accurately displaying the page size identifier in the setup and context menus, the standard page identifier is now appended to the page size meta command. For example:
0 LPUB PAGE SIZE 8.5000 14.0000 Legal
0 LPUB PAGE SIZE LOCAL 8.5000 11.0000 Letter
0 LPUB PAGE SIZE LOCAL 5.8000 8.3000 A5
0 LPUB PAGE SIZE LOCAL 5.8678 8.3456 Custom
Along with the width and height values, if the page size is non-standard, the identifier "Custom" will be automatically used. Additionally if an identifier is not present, the identifier "Custom" will automatically used. The page identifier is displayed in the Page Setup dialogue and Size/Orientation change context menu dialogue.
Also, the LPub3D print/export function no longer needs to parse the model file to capture, in advance, page sizes. This capture is performed during the existing page parse and load functions and is exposed to the print routines during printing/exporting. This change was necessary to better enable mixed-size page export/printing where it is necessary to 'look ahead' to get the next page's size and orientation parameters in order to configure the printer engine before processing the page.

Fix: The PNG output of a model with various page orientations is not correct (r824)
* Cleared page buffer before rendering each page. Also corrected a typo causing page range to sometimes not work for image exports.

(2016-10-06, 15:31)Trevor Sandy Wrote: Fix: Page size and orientation processing update (r826/833)
* Further industrialization of the print/export module. This update streamlines the process and realizes some performance gains. There are some key changes. Notably, page orientation and page size are now mutually exclusive. This means when switching from Portrait to Landscape, accompanying the orientation meta with a transposed page size meta no longer required or managed. Here is an illustration:
Previous behaviour when editing a page size change required the following meta commands:
0 STEP
0 LPUB PAGE ORIENTATION LOCAL LANDSCAPE
0 LPUB PAGE SIZE LOCAL 11.0000 8.5000
Note that the page width and height have been transposed. Going forward, transposition of the page width and height when switching from Portrait to Landscape is automatically managed by LPub3D.
NOTE: This update is NOT backward compatable. An accompanying transposed page size meta to indicate the switch from portrait to landscape as shown above will be treated as a new page size meta for that page. Consequently, using this meta to 'switch' orientation will actually result in NOT switching the orientation as LPub3D will automatically switch again the switched page size meta.
If the user is only interested in changing the orientation, the proper meta command going forward will be:
0 STEP
0 LPUB PAGE ORIENTATION LOCAL LANDSCAPE
To help with accurately displaying the page size identifier in the setup and context menus, the standard page identifier is now appended to the page size meta command. For example:
0 LPUB PAGE SIZE 8.5000 14.0000 Legal
0 LPUB PAGE SIZE LOCAL 8.5000 11.0000 Letter
0 LPUB PAGE SIZE LOCAL 5.8000 8.3000 A5
0 LPUB PAGE SIZE LOCAL 5.8678 8.3456 Custom
Along with the width and height values, if the page size is non-standard, the identifier "Custom" will be automatically used. Additionally if an identifier is not present, the identifier "Custom" will automatically used. The page identifier is displayed in the Page Setup dialogue and Size/Orientation change context menu dialogue.
Also, the LPub3D print/export function no longer needs to parse the model file to capture, in advance, page sizes. This capture is performed during the existing page parse and load functions and is exposed to the print routines during printing/exporting. This change was necessary to better enable mixed-size page export/printing where it is necessary to 'look ahead' to get the next page's size and orientation parameters in order to configure the printer engine before processing the page.

Hi Trevor,

I am experiencing difficulty with the page size and orientation.
Setting things up in a new LDraw file does not give the meta for page size like you describe.
In my file setting up the page size A4 and orientation landscape gives this:

My model is rather big (32 by 48 studs). Scaling the assem size to 0.7 should fit, but the image is cut off.
This cut off seems exactly the way it should when the orientation is portrait. So I guess there's something wrong there?

I am experiencing difficulty with the page size and orientation.
Setting things up in a new LDraw file does not give the meta for page size like you describe.
In my file setting up the page size A4 and orientation landscape gives this:

My model is rather big (32 by 48 studs). Scaling the assem size to 0.7 should fit, but the image is cut off.
This cut off seems exactly the way it should when the orientation is portrait. So I guess there's something wrong there?

I experienced this bug too with ldglite rendering.
have you tried with ldview4.2

You can download from sourceforge.net or check for updates in your existing installation.

LPub3D 2.0.14.838.2

Features and enhancements
------------
Fix: File reload after external source change breaks page drop-down combo dialogue(r837)
* When a file is reloaded after being changed by an external source, the drop-down menu for selecting a page doesn't work until after navigating using another method. Corrected.

Fix: Extra characters "%3" in margin meta and page size meta does not display the page size identifier(r835)
* Oops, allocated the page size identifier variable to the wrong meta - should have been allocated to page size meta instead of units meta (units meta is used for setting the margin). Consequently, the page size meta is missing the size identifier (A4, Letter, etc...) because the place-holder to pass the variable is not there. Both issues are now corrected.

Fix: On reset all caches LPub3D returns to first page (r843)
* LPub3D will return to the page on which it was when reset all caches launched.

Fix: Fade position lost on page refresh (r842)
* Refresh page (in the LDraw editor) and closing the preference dialogue will refresh the loaded model file after which the fade position is lost and the entire first step on the page is incorrectly faded. This behaviour has been corrected.

Fix: INSERT MODEL meta places meta in the wrong place (r841)
* When there are steps after the last part-added step, the INSERT MODEL meta added by LPub3D is placed after the STEP meta instead of before it.

(2016-11-13, 9:47)Robert Wrote: With the versions 2.0.14 / 2.0.15, when i export as pdf or image, i have a blank page ... i reset all caches, but it's the same.
It work with 2.0.13 ...

Hi Robert,

If I well understand, you are saying that you are unsuccessful to export your model file as pdf or image ? Upon export, you only receive a blank page ?
I can't reproduce your behaviour, so can you PM(or email) me a copy of your model file that produce the behaviour you are experiencing ? You can see my email in the Help/About menu.

(2016-11-13, 9:47)Robert Wrote: With the versions 2.0.14 / 2.0.15, when i export as pdf or image, i have a blank page ... i reset all caches, but it's the same.
It work with 2.0.13 ...

Hi Robert,

I think I found the problem. The page size is not captured during printing unless an explicit definition of the page size meta is present in the model file. This is a bug and will be fixed in the next release 2.0.17.

As an immediate work around, add the meta command below before the first step in your model file and let me know if this resolves your problem ?

Code:

0 !LPUB PAGE SIZE GLOBAL 8.5000 11.0000 Letter

Note that you can use whatever size parameters and page identifier you wish.

Hey Trevor. I haven't used LPub3D for some time now, but I got some new projects again, so I'll be using it extensively for the next months.
It's great to see all the new features and fixes in action.

However, in my short 15 minutes of playing with, I got a few things (note: I'm using the newest version):

I misplaces the step number, the step number is slightly out of the page, which means it gets cut off when I export it. This is the standard layout when opening a model. I've tried changing every margin I could find, without any success. Did I overlook something? I hope I/you can fix this soon, because I'd like to finish the instructions I'm working on as soon as possible

I haven't investigated this one very much. I think I saw a little error. When a submodel is used multiple times, you get the X2 or whatever number to indicate the amount you have to make. However, when I place all steps except the last one on a single page, it shows X2 on the first, but the first page doesn't contain the last step. The last step is on the next page. Again, I haven't investigated this one very much, so I just maybe I didn't look very well. EDIT: I've confirmed this behavior now.

That's it for now.
Thanks!

EDIT: I forgot to mention that I did a quick export of my LDraw file and somewhere around the middle of the file, all pages were blank. I don't know if this is because I used my browser to view the pdf (maybe it has a page limit) or LPub3D is doing something wrong, but Robert's post above does make me wonder...

Merlijn Wissink Wrote:I misplaces the step number, the step number is slightly out of the page, which means it gets cut off when I export it. This is the standard layout when opening a model. I've tried changing every margin I could find, without any success. Did I overlook something?

Corrected in latest release.

Merlijn Wissink Wrote:When a submodel is used multiple times, you get the X2 or whatever number to indicate the amount you have to make. However, when I place all steps except the last one on a single page, it shows X2 on the first, but the first page doesn't contain the last step. The last step is on the next page. Again, I haven't investigated this one very much, so I just maybe I didn't look very well. EDIT: I've confirmed this behavior now.

Sorry but I don't understand your description of this issue. Could you PM me an example model file that generates the behaviour you describe or screenshot(s) of what you are experiencing and what you expect ?

Merlijn Wissink Wrote:I did a quick export of my LDraw file and somewhere around the middle of the file, all pages were blank.

I can't reproduce this behaviour. Could you PM me a copy of the model file generating this behaviour ? Thanks.

Merlijn Wissink Wrote:When a submodel is used multiple times, you get the X2 or whatever number to indicate the amount you have to make. However, when I place all steps except the last one on a single page, it shows X2 on the first, but the first page doesn't contain the last step. The last step is on the next page. Again, I haven't investigated this one very much, so I just maybe I didn't look very well. EDIT: I've confirmed this behavior now.

Sorry but I don't understand your description of this issue. Could you PM me an example model file that generates the behavior you describe or screenshot(s) of what you are experiencing and what you expect ?

Well, I don't have an example (anymore), but it's quite easy to reproduce.. I'll try explaining one more time, otherwise I'd have to create an example

Imagine you have a submodel with 5 steps and it's used 2x times in the parent-model. Now, the first 4 steps fit on a single page, so you create a multi-step page with the first 4 steps of the submodel. The last step (step 5) is on the next page. However, the x2 already shows up on the first page (under step 4) even though it should appear at the end of the submodel (at step 5). Hope that makes sense.

(2016-11-19, 15:29)Trevor Sandy Wrote:

Merlijn Wissink Wrote:I did a quick export of my LDraw file and somewhere around the middle of the file, all pages were blank.

I can't reproduce this behavior. Could you PM me a copy of the model file generating this behavior ? Thanks.

Cheers,

I don't know what it was. It was definitely a malformed pdf (I tried opening it in another viewer), but after exporting a 2nd time the problem was gone and never re-appeared...

(2016-11-19, 20:18)Merlijn Wissink Wrote: [quote='Trevor Sandy' pid='23891' dateline='1479569385']
Sorry but I don't understand your description of this issue. Could you PM me an example model file that generates the behavior you describe or screenshot(s) of what you are experiencing and what you expect ?

Well, I don't have an example (anymore), but it's quite easy to reproduce.. I'll try explaining one more time, otherwise I'd have to create an example

Imagine you have a submodel with 5 steps and it's used 2x times in the parent-model. Now, the first 4 steps fit on a single page, so you create a multi-step page with the first 4 steps of the submodel. The last step (step 5) is on the next page. However, the x2 already shows up on the first page (under step 4) even though it should appear at the end of the submodel (at step 5). Hope that makes sense.

(2016-11-19, 15:29)Trevor Sandy Wrote: I can't reproduce this behavior. Could you PM me a copy of the model file generating this behavior ? Thanks.

Cheers,

I don't know what it was. It was definitely a malformed pdf (I tried opening it in another viewer), but after exporting a 2nd time the problem was gone and never re-appeared...

Merlijn Wissink Wrote:Imagine you have a submodel with 5 steps and it's used 2x times in the parent-model. Now, the first 4 steps fit on a single page, so you create a multi-step page with the first 4 steps of the submodel. The last step (step 5) is on the next page. However, the x2 already shows up on the first page (under step 4) even though it should appear at the end of the submodel (at step 5). Hope that makes sense.

When I turn off page numbers, it also removes all notations of how many times a submodel has to be build (e.g. x2) except for callouts.

When creating a call-out, it copies the ROTSTEP (if any) of the parent model, to avoid this I have to force the submodel to use its own rotation steps by making the first step a ROTSTEP END.

A bit the same as above: when creating a call-out, the call-out uses the same model-scale as the parent page. This one however cannot be avoided, even if I add a scale into the submodel, it still uses the scale of the parent model.

There were a few other things which I forgot to write down. Whoops. I'm sure I come across them again, so no worries

When I turn off page numbers, it also removes all notations of how many times a submodel has to be build (e.g. x2) except for callouts.

When creating a call-out, it copies the ROTSTEP (if any) of the parent model, to avoid this I have to force the submodel to use its own rotation steps by making the first step a ROTSTEP END.

A bit the same as above: when creating a call-out, the call-out uses the same model-scale as the parent page. This one however cannot be avoided, even if I add a scale into the submodel, it still uses the scale of the parent model.

Merlijn,

These are all old LPub items. I don't think they are bugs but limitations.

For item 1, instance count is by default placed relative to page number so if no page number then no instance count. I'll correct this in the next release 2.0.17. Update: This has been corrected.

Item 2/3, although callouts have dedicated attributes, ROTSTEP and scale are not dedicated attributes for callouts. In fact, these attributes are both associated with assemblies. You can select the assembly in the callout and use its context menu to change the scale.

When I turn off page numbers, it also removes all notations of how many times a submodel has to be build (e.g. x2) except for callouts.

When creating a call-out, it copies the ROTSTEP (if any) of the parent model, to avoid this I have to force the submodel to use its own rotation steps by making the first step a ROTSTEP END.

A bit the same as above: when creating a call-out, the call-out uses the same model-scale as the parent page. This one however cannot be avoided, even if I add a scale into the submodel, it still uses the scale of the parent model.

Merlijn,

These are all old LPub items. I don't think they are bugs but limitations.

For item 1, instance count is by default placed relative to page number so if no page number then no instance count. I'll correct this in the next release 2.0.17. Update: This has been corrected.

Item 2/3, although callouts have dedicated attributes, ROTSTEP and scale are not dedicated attributes for callouts. In fact, these attributes are both associated with assemblies. You can select the assembly in the callout and use its context menu to change the scale.

Let me know how you would expect items 2 and 3 to behave.

Cheers,

I have no idea if they're old LPub or not. I'm so used to LPub3D now I barely remember what is was like using LPub (which is a good thing)

Regarding item 1: quite funny explanation, haha. Never realized it was relative to the page number (and thus disappearing when the page number was gone). I'll take another good look at number 2 and 3 and I'll report back to you.

Also, another bug I discovered today (although I haven't verified/investigated this one: my model has the first 1/3 of the instructions in portrait mode, the 2nd 1/3 in landscape mode and the last 1/3 in portrait again. When I export however, the first 1/3 is correctly portait, the 2nd 1/3 is correctly landscape, but the last 1/3 is still landscape and doesn't go back to portrait (and thus a lot of stuff is cut off).

(2016-11-19, 20:23)Merlijn Wissink Wrote: Also, another bug I discovered today (although I haven't verified/investigated this one: my model has the first 1/3 of the instructions in portrait mode, the 2nd 1/3 in landscape mode and the last 1/3 in portrait again. When I export however, the first 1/3 is correctly portait, the 2nd 1/3 is correctly landscape, but the last 1/3 is still landscape and doesn't go back to portrait (and thus a lot of stuff is cut off).

(2016-11-19, 20:23)Merlijn Wissink Wrote: Also, another bug I discovered today (although I haven't verified/investigated this one: my model has the first 1/3 of the instructions in portrait mode, the 2nd 1/3 in landscape mode and the last 1/3 in portrait again. When I export however, the first 1/3 is correctly portait, the 2nd 1/3 is correctly landscape, but the last 1/3 is still landscape and doesn't go back to portrait (and thus a lot of stuff is cut off).

Below is an example model that starts with portrait, then landscape, then back to portrait. Copy, save and let me know if your installation properly processes this content ?

Cheers,

Well, aside from if that works or not, the editor correctly showed portrait/landscape/portrait so the exporter didn't export 100% the same as shown. So there's at least something wrong

My situation: I have a model with 1 big submodel that has the landscape orientation. The rest of the model is just portrait. I added a 2nd '0 !LPUB PAGE ORIENTATION GLOBAL PORTRAIT' command on the step that the submodel was added, this fixes the export problem mostly. The 3rd 1/3 now correctly exports to portrait again, except for the first page (where the landscape model is added into the main model); that one is still landscape (and again, the editor shows it as portrait...). I could send you the file if you want.

You can download this release from sourceforge.net or check for updates in your existing installation.

Change Log:

LPub3D 2.0.16.858.2

Features and enhancements
------------
Fix: Prompt to download LDraw archive when archive not provided (r856)
* When a portable distribution of LPub3D (e.g. when distributed in AIOI) does not include the LDraw archive libraries, LPub3D will prompt the installation user to download or select the LDraw library archives if they are not detected. This update allows portable distributions of LPub3D to exclude the official and unofficial LDraw library archive files. Note that if a portable distribution includes only the official LDraw library archive (complete.zip), LPub3D will automatically build the unofficial library archive (lpub3dldrawunf.zip) file from content in the LDraw\unofficial directory; however, subdirectory parts and p will be ignored so the created unofficial library archive will NOT contain the default unofficial library parts and primitives. To fully update the unofficial library archive file under this scenario, select Tools/Refresh LDraw Unofficial Parts from the LPub3D menu bar to update the lpub3dldrawunf.zip with the latest unofficial parts and primitives.

Fix: Cover page attributes displayed outside of page (r853)
* Page attributes placed outside of page when displaying individual attributes. Attributes on both front and back cover pages were experiencing this behaviour. The behaviour is now corrected. Refer to features and enhancements for LPub3D 2.0.11.816.2 to review additional details on manipulating page attributes.

Fix: Unable to create a new line in text items - e.g. Model Description (r851)
* It is now possible to split text in text boxes and all editable page attributes - e.g. model description, LEGO disclaimer etc... When you select a text item, the cursor is placed at the very beginning of the dialogue. Use your arrow keys to move the cursor to the desired position of the dialogue.
To split a line simply hit the "enter" key on your keyboard. It is also possible to create a new line by inserting inserting the newline characters \n.
One can also add "quoted texts" in test items. Just like adding a new line, simply type " before and after the content you wish to quote. It is not necessary to enter an escape character \ but entering an escape character before the \" is also supported.

Fix: The step number is slightly off of the page when using default settings (r850)
* Page header and footer width is now matched with the size and orientation of the displayed page. One can also change the "Relative To" settings from header/footer to page using the context menu/Move Step Number dialogue. For example, the step number on single step pages default placement is relative to the invisible page header - which can be managed in the page setup dialogue. Alternatively, step number placement on a single step page can be set relative to the page using the context menu as described earlier.

Fix: Page movable and selectable in the graphics scene (r849)
* Page is now fixed and cannot be selected within the graphics scene.

Fix: Drag and drop model file (r848)
* Open model file using drag and drop. Note that only one file at a time can be opened so dragging and dropping multiple files will only open the first file in in the list of selected files.

I hope you don't mind me asking for all these changes/fixes, because coming weeks/months I'm working on some bigger projects so I'll come across more things as I go along...

This time:
I often edit the pdf after the export with some minor additions (a little text here, an arrow there, a quick fix on that page etc.). Sometimes I also decide to add a background into the pdf itself. However, the pdf export always adds a page-sized square with the color of the page-background, as background. I could understand this if the page background was any other color than white, but for white it's so useless (I mean, if I delete the white square, the page is white so there is zero difference). So, if I want to add a background in the pdf, I first have to go over every page and remove the white square. This problem already existed in the original LPub, so it's not your fault

Then I saw this new option: a transparant background. I thought: 'wow, he actually implemented a fix for this problem! yay!', but even when exporting with a transparant background, it still adds those white squares

Also, it seems that adding an image background in LPub3D itself is also broken: I selected an image, but then all pages become transparant and there's no image to be found.

(2016-11-20, 8:10)Merlijn Wissink Wrote: I hope you don't mind me asking for all these changes/fixes...

It's not a problem. Reporting issues helps all who use the software.

Using the default setting 'Submodel Level Color" or None(transparent), I don't see any squares in my output other than those associated with page items - PLI, Assy, Callout etc... I'm reviewing the output using Adobe Acrobat X Pro. You're going to have to send some screenshots to see what you're talking about.

Let me know if the output file attached includes the squares you are talking about ?

Merlijn Wissink Wrote:Also, it seems that adding an image background in LPub3D itself is also broken: I selected an image, but then all pages become transparent and there's no image to be found.

(2016-11-20, 8:10)Merlijn Wissink Wrote: I hope you don't mind me asking for all these changes/fixes...

It's not a problem. Reporting issues helps all who use the software.

Using the default setting 'Submodel Level Color" or None(transparent), I don't see any squares in my output other than those associated with page items - PLI, Assy, Callout etc... I'm reviewing the output using Adobe Acrobat X Pro. You're going to have to send some screenshots to see what you're talking about.

Let me know if the output file attached includes the squares you are talking about ?

Well, you can't see the squares.

I'm using Adobe Acrobat DC Pro, but I'm pretty sure you can also edit pdf files in X Pro.
When you open the file in Adobe, then start editing the pdf. Try to 'select' the background. You'll see you suddenly have selected a giant white square with the size of the page. Then delete the square and you'll see there's nothing left.

When I add a background in Adobe, I have to delete all those white rectangles, because the background appears under those.

But, I just realized the following: when I add a background in Adobe, it also adds an image to every page which I then can delete on a page-by-page basis, just like the white rectangles (just with an image). So, I don't know if this is really a 'problem' or just pdf behavior that I don't like.

Still, it would be nice if you could stop producing these rectangles if the background is pure white (#ffffff), since they don't seem to be necessary (when I delete them, the background is still white)

(2016-11-20, 13:52)Merlijn Wissink Wrote: I'm using Adobe Acrobat DC Pro, but I'm pretty sure you can also edit pdf files in X Pro.
When you open the file in Adobe, then start editing the pdf. Try to 'select' the background. You'll see you suddenly have selected a giant white square with the size of the page. Then delete the square and you'll see there's nothing left.

Still, it would be nice if you could stop producing these rectangles if the background is pure white (#ffffff), since they don't seem to be necessary (when I delete them, the background is still white)

Ok, I found your "squares" - they're actually Acrobat's image XObjects which are generated by the pdf print engine during construction of the pdf page. I don't know if there's anything I can do in my code to change this behaviour. I imagine, one would have to subclass the Qt print engine to manipulate this level of object. Sorry

(2016-11-20, 13:52)Merlijn Wissink Wrote: I'm using Adobe Acrobat DC Pro, but I'm pretty sure you can also edit pdf files in X Pro.
When you open the file in Adobe, then start editing the pdf. Try to 'select' the background. You'll see you suddenly have selected a giant white square with the size of the page. Then delete the square and you'll see there's nothing left.

Still, it would be nice if you could stop producing these rectangles if the background is pure white (#ffffff), since they don't seem to be necessary (when I delete them, the background is still white)

Ok, I found your "squares" - they're actually Acrobat's image XObjects which are generated by the pdf print engine during construction of the pdf page. I don't know if there's anything I can do in my code to change this behaviour. I imagine, one would have to subclass the Qt print engine to manipulate this level of object. Sorry

Cheers,

Yeah, I already kind of expected something like that. But still, I had a little bit of hope

In any case; what's the use of a 'transparant' background then anyway? What does it do differently than a white background (since both options export a white background-rectangle)?

(2016-11-20, 18:25)Merlijn Wissink Wrote: In any case; what's the use of a 'transparant' background then anyway? What does it do differently than a white background (since both options export a white background-rectangle)?

Good question, perhaps you can ask Kevin. Background none (transparent) was brought forward from LPub.

The difference between setting "Submodel Level Color" and none (transparent) should be obvious (each level has a different color as you can see) even though at submodel level 0, the background color is white.

Merlijn Wissink Wrote:Also, it seems that adding an image background in LPub3D itself is also broken: I selected an image, but then all pages become transparent and there's no image to be found.

I can't reproduce this behaviour.

For me setting a background image works as designed:

Well, if I take the exact file I sent you, and add an image (from the desktop) all pages become transparant (the background that is).
Also, I just discovered that if I choose 'Tiled' instead of 'Stretch Picture' LPub3D just hangs and seems to do nothing (I'm not sure if it's doing A LOT of stuff or if it's just crashing).

You can download this release from sourceforge.net or check for updates in your existing installation.

Change Log:

LPub3D 2.0.17.863.2

Features and enhancements
------------
Fix: Inconsistent page size/orientation transition (r862)
* Size and orientation transition is inconsistent between the editor and export for mixed orientation output. Editor and export page orientation corrected to behave the same. Here are some notes to describe how to use the different metas:
- Use the page context menu to set size and/or orientation to ensure proper meta command syntax.
- GLOBAL (e.g 0 !LPUB PAGE ORIENTATION GLOBAL PORTRAIT) meta keyword should only be used at the header of the top level model file - if you are manually adding meta commands in the LDraw editor.
- LOCAL (e.g 0 !LPUB PAGE ORIENTATION GLOBAL PORTRAIT) meta keyword will scope the meta command to only the current step - if you are manually adding meta commands in the LDraw editor..
- When the LOCAL keyword is absent (e.g. 0 !LPUB PAGE ORIENTATION PORTRAIT), the meta command takes on the same behaviour as if the GLOBAL keyword is used - i.e. the meta command takes on a global scope from the point where it is used - unless it is superseded by a new meta command.
- When manually setting size and/or orientation on a child submodel (i.e. using the LDraw editor), place your command in the child submodel instead of placing it in the parent model. For MULTI_STEP(s), place the size orientation at the bottom of the MULTI_STEP - just before 0 !LPUB MULTI_STEP END.

Fix: Empty output after export to pdf or images (r861)
* The page size was not captured during export (pdf or images) unless an explicit definition of the page size meta command is present in the model file (e.g. 0 !LPUB PAGE SIZE GLOBAL 8.5000 11.0000 Letter). This behaviour is now corrected.

Fix: When page number is not displayed, the submodel instance count is also not displayed (r860)
* Instance count is by default placed relative to page number so, by default, if page number is not displayed then instance count is also not displayed. This behaviour is now changed to automatically set the instance count relative to the page if the page number is not displayed. As a result, the instance count will display regardless of the display status of the page number.

You can download this release from sourceforge.net or check for updates in your existing installation.

Change Log:

LPub3D 2.0.18.876.2

Features and enhancements
------------
Fix: Instance count placement when page number not displayed (r874)
* Instance count is placed relative to page number by default. When page number is not displayed, LPub3D will re-assign the instance count to any or the four page attributes, url, email, copyright, and author (default) displayed at the left bottom area of the page. If no page attributes are displayed, the instance count is assigned to the bottom left inside corner of the page.

Fix: Fade part not displayed in assembly image (r872)
* The faded part is not rendered or displayed in the CSI step image. The non-faded part occurrence is rendered successfully and the faded part is displayed in the viewer.The problem persists after regenerating fade parts and clearing the cache. In some scenarios, particularly when LPub3D is launched with fade=Off and then fade is set to fade=ON using the Preferences menu after a model file is loaded, it is possible that the fade directory is not communicated to the renderer so no fade part image is rendered. This behaviour has been corrected.
With the updated behaviour, the fade search directories are updated on any change to the Fade Step check-box in the Preferences General tab. If the fade step is set to ON, fade directory with part file content will be added to the search directory. When fade step is set to OFF, the fade directory will be removed.

Fix: True page background transparency (r871)
* When the page background is set the true transparent, it is not possible to display the background context menu so many page functions will not be accessible. To accommodate true transparency and enable the available page editing functions, when a page background is set to "none(transparent)" by the user, the page is set to white with alpha=1 during page editing but switched to true transparent for exporting/printing. This way, the user will have the ability to manipulate the page components while editing the document.

Fix: Previewing the current page (single page) produces a blank page (r870)
* This behaviour has been corrected.

Fix: Page size precision to 4 decimal places (r869)
* When using some page sizes (e.g. A4), there was a thin white band at the right/bottom edge of the generated PDF pages when the background is set to colour or image. This issue resulted from using incorrect page sizes. The correct page size in inches sometimes require 4 digits of precision but were rounded to only 1 digit. All page sizes have been set to 4 digits of precision.

Fix: Find button in LDraw editor (r867)
* Find button added to LDraw editor. The find dialogue will open with the word currently under the cursor. Therefore, an efficient use pattern is to place the cursor above the word you wish to search and click the search button.

Fix: Display message for mixed page size and orientation (r866)
* When previewing a pdf export, the user has to option to present or suppress the message indicating there are different orientations and/or sizes in the preview. The Qt print preview does not play well with mixed pages sizes. This message informs the user of this fact. Additional Cleanup.

Fix: Misplaced submodel occurrence (r865)
* When a submodel ends with a single step and the next to the last step is a multi-step, the submodel occurrence number (if used more than 1x in the parent model) is placed both at the multi-step and the last step in the child model. Under this scenario, the corrected behaviour places the occurrence number only at the last step.

I thought of another feature that might be nice to have: I was looking through the building instructions for the Porsche model (42056) and I saw that they use a single sequence for the step numbering. Submodels do not have their own numbering starting at 1. The whole book just starts at 1 and ends at 856. Obviously call-outs do have their own numbering. And it actually looked quite nice.

So, is it possible to implement something like that in LPub3D? Where the whole file just uses 1 sequence for the step numbering, regardless of what submodel you're into (except when you turn a submodel into a call-out).

(2016-12-03, 8:50)Merlijn Wissink Wrote: So, is it possible to implement something like that in LPub3D?

Indeed, it's possible and somewhat straightforward to do too. Instead of automatically resetting the step number at every new submodel (or callout), I can add a preference setting to optionally reset or not.

For LPub3D 2.1 and beyond, there are already quite a few interesting new features coming from the Porsche GTS instructions book, I'll add this one also.

(2016-12-03, 8:50)Merlijn Wissink Wrote: So, is it possible to implement something like that in LPub3D?

Indeed, it's possible and somewhat straightforward to do too. Instead of automatically resetting the step number at every new submodel (or callout), I can add a preference setting to optionally reset or not.

For LPub3D 2.1 and beyond, there are already quite a few interesting new features coming from the Porsche GTS instructions book, I'll add this one also.

Cheers,

Any update on the continued step number? I'm not in a hurry or anything, but it seems to be a much wanted feature. I've already heard multiple people looking for this feature in the past few weeks alone.

You can download this release from sourceforge.net or check for updates in your existing installation.

Change Log:

LPub3D 2.0.19.877.2

Features and enhancements
------------
Fix: Callout not displayed and part count incorrect when loading a model using multiple, separate ldr-format files (r877)
* These behaviours were introduced in LPub3D 2.0.0. The immediate work around is to merge the individual ldr files into a single MPD-format file. However, these behaviours are now corrected.

(2016-12-09, 9:26)Merlijn Wissink Wrote: ...callout in a callout doesn't look very well :
I don't know what's happening here, but it sure isn't what it's supposed to do. Any ideas?

I didn't know nested callouts were possible in LPub3D or LPub for that matter

I certainly haven't released any functionality of the sort; furthermore, the legacy LPub code suggest this behaviour is explicitly forbidden.

Code:

// This is what's supposed to happen when a callout [begin] meta is encountered.
case CalloutBeginRc:
if (callout) {
parseError("Nested CALLOUT not allowed within the same file",current);
} else {
callout = new Callout(curMeta,view);
callout->setTopOfCallout(current);
}
break;

Did the behaviour you expected exist on any earlier version of the software?

It would be interesting to see an example of the LPub meta pattern you used in the model file to produce nested callouts.

I'm finally back, having time for ldraw things again. I see you have released several versions since summer holidays, that looks nice. Did you have time for a research why LPub3D stopped being compilable on Linux, too? Can I still help you with that in any way?

You know - it's a strong feeling of pity as original LPub was for both Linux and Windows and today I see many nice features but as pictures in ldraw forum only ;(

(2016-12-09, 12:24)Milan Vančura Wrote: Did you have time for a research why LPub3D stopped being compilable on Linux, too?

Between v2.0.0 and v2.0.7, I was compiling my release distributions with MSVC 2015 which I understand broke Linux compatibility. From 2.0.8 I reverted back to exclusively releasing MinGW compiled distributions (x86 and x64).

It is my understanding that LPub3D can run under POSIX-compliant operating systems, such as Linux, Mac OSX, & BSD using WINE HQ (www.winehq.org ).

If you are ok to run the currently available distributions of LPub3D - WINE is your friend

(2016-12-09, 12:24)Milan Vančura Wrote: Can I still help you with that in any way?

Sure, the LPub3D source should be cross-platform compile compatible because I develop exclusively with the QtCreator/MinGW tool chain.

If you care to share any content on compiling on and packaging for Linux, I'll be pleased to incorporate and validate the build and release.

If you care to compile and package LPub3D, you can see the source here.

(2016-12-09, 19:49)Trevor Sandy Wrote: Sure, the LPub3D source should be cross-platform compile compatible because I develop exclusively with the QtCreator/MinGW tool chain.

If you care to share any content on compiling on and packaging for Linux, I'll be pleased to incorporate and validate the build and release.

Thanks, Trevor!
This version looked much more promising so I spent some hours on that and made it working on Linux, natively.
Qt part was easy, there were only details to fix. The other parts contained, sometimes, Windows-specific code or #ifdef's were not used 100% properly. And, of course, some filenames were referenced with improper character case, as Windows do not care about that. Plus the "wrapper" header file unistd.h, specific for Windows, was placed in a way it was impossible to #define how not to use it on Mac and Linux.

I fixed all that, you can see it in the first git commit. The second one is a fix of one annoying issue coming from old LPub4 times: the file mask of Open file dialogs caused people on Mac and Linux saw nothing in the dialog. This commit applies on top of the first one. Both are ready to be used directly by git ('git am') so you can check them easily.

Thanks again for your work, it was nice feeling to see LPub3D working, in the end Even there are still some problems (and they don't look Linux-specific), I report them later. Of course, tell me if you need anything more about Linux, I hope LPub3D stays multiplatform since now and I'll be able to prepare Linux binary package every time you release new version.

(2016-12-13, 7:41)Milan Vančura Wrote: ...tell me if you need anything more about Linux, I hope LPub3D stays multiplatform since now and I'll be able to prepare Linux binary package every time you release new version.

Excellent !

I'll apply the relevant updates to my development branch so it will be much easier to compile for Linux going forward.

I actually already have a running Mac port and I'm aware of some issues like the splash screen on startup when installing a fresh instance of LPub3D. I have already addressed items, including some you have also addressed for 2.0.6 (e.g. unistd.h), ldrawini_global.h, updates to ldrawini, quazip modules and several classes in the mainApp module.

Many thanks for your effort on the port. I'll be sure to add you to the list of credits for this contribution.

I'm glad it looks we can cooperate this way. If I had the read access to your development git branch I could prepare commits based on the current code - that saves time of both me (some fixes already done) and you (every merge easier for you). I can continue sending commits via forum or e-mail so I do not need any write access to you tree. What do you think about that?

Also, it would be great if you can have a virtual machine with Linux so you can test your builds there. Of course, I may help you with this if needed. Installation of Debian or Ubuntu is easy, same about openSuse or Fedora.

For example, the following is a list of issues I was hit by - and I plan to work on them if needed, after Christmas:

First run - the creation of the first user configuration:

* LPub3D creates new directory tree on its own ($HOME/.local/share/LPub3D Software/LPub3D/) but it forgets to create some files there and complains to me instead: "extras/titleAnnotations.lst", "extras/fadeStepColorParts.lst", "extras/pliSubstituteParts.lst".

* to make it more annoying, it cries later about missing titleAnnotations.lst file before rendering each and every step

* Preferences: after typing the ldglite path manually the roller "preferred renderer" does not get any value and "Required settings are missing..." warning pops up after hitting "OK" button. The workaround is to click on "Browse", even I do not need to change the path. Then, everything works.

* LPub3D asks me for both complete.zip and ldraw directory - why??

* LPub3D tries to get some archive of unofficial parts - how can I point it to my "Unofficial" subdirectory of my ldraw tree instead? Same as what I use and/or used with LDCad, LPub4, SR3D Builder...

in the application:

* ctrl-O does not work

* ctrl-S tries to "save the project" even when nothing is open

* I do not understand how to "synchronize" the angle of current step and the angle in that 3D window. A different angle is shown there and if I rotate with that 3D view and press "insert rotstep" button, I get completely different view in the rotstep than it is shown in the 3D sidebar.

generic:

the program crashes with segmentation fault in several cases, I try to map them and solve what I can.

I expect more but this is what I have found so far. It looks like a set of problems big enough to prevent me getting bored between Christmas and the end of year I'd be very glad if you can tell me more: what makes sense to spend time with, what you have already solved in your development branch, what looks like a Linux-specific problem etc.

A bug I cannot reproduce now but it happened twice: after first run and all those configuration questions, program set the LDraw path to $HOME/.local/share/LPub3D Software/LPub3D/ldraw directory which it created but left empty. Then it was a surprise why LPub3D looks working somehow but I see empty pages, only a box with numbers of each part amount was there, no pictures. After long debugging I found it was just a matter of this misconfiguration.
But, as I wrote above, I'm not able to reproduce this behavior now, I forgot that combination of my options which caused this.

(2016-12-14, 23:06)Milan Vančura Wrote: A bug I cannot reproduce now but it happened twice: after first run and all those configuration questions, program set the LDraw path to $HOME/.local/share/LPub3D Software/LPub3D/ldraw directory which it created but left empty. Then it was a surprise why LPub3D looks working somehow but I see empty pages, only a box with numbers of each part amount was there, no pictures. After long debugging I found it was just a matter of this misconfiguration.
But, as I wrote above, I'm not able to reproduce this behavior now, I forgot that combination of my options which caused this.

Milan, the behaviour described here is not due to the reason stated. In fact, it is because of the 3D viewer part cache corruption. Here are the details:

Symptom:
After opening a model file, the status indicates 0 parts were loaded. The log states Item [<part.dat>] not in the LPub3D archives. <path>/lpub3dldrawunf.zip <path>/complete.zip. This x11-specific behaviour presents on launching LPub3D after a previous abnormal termination (crash).Problem:
Corrupt 3D Viewer (LeoCAD) cacheSolution:
Delete the cache at $HOME/.cache/LPub3D Software and relaunch the application.Root Cause:
Abnormal termination of the application

I have taken a first look at the x11 port and I believe there are some areas, notably the user menus, to address before a reasonable release can be qualified.

(2016-12-14, 22:57)Milan Vančura Wrote: If had the read access to your development git branch I could prepare commits based on the current code - that saves time of both me (some fixes already done) and you (every merge easier for you). I can continue sending commits via forum or e-mail so I do not need any write access to you tree. What do you think about that?

You should have read access. Read permissions are enabled for anonymous users by default. If you care to set up and forward your sourceforge user id, I'll be pleased to add you to the repository with read/write access. Or, we can continue to exchange via mail/posts. You can see my email in the help/about dialogue.

(2016-12-14, 22:57)Milan Vančura Wrote: Also, it would be great if you can have a virtual machine with Linux so you can test your builds there. Installation of Debian or Ubuntu is easy, same about openSuse or Fedora.

I'm currently running an Osboxes.org CentOS 7 distribution as well as OSX Sierra - both via VM. I am launching LPub3D on CentOS without issue but I can't seem to find any binaries for the renderers (ldglite, LDView) so I'm blocked at the moment. I setup and compile the renderers but I think it would be more efficient to switch to another Linux distribution where the renderers are already available. What do you think is the optimum Linux distribution for LDraw tools ?

(2016-12-14, 22:57)Milan Vančura Wrote: I'd be very glad if you can tell me more: what makes sense to spend time with, what you have already solved in your development branch, what looks like a Linux-specific problem etc.

Here are some useful guidance and insights on the behaviours you encountered:

- I have updated the latest release source (v2.0.19) with the changes required for POSIX/x11 compatibility and created a new x11 branch on sourceforge. The LPub3D master branch has also been updated to the latest release.

- To best understand the internals of LPub3D, I would recommend performing a thorough read of the README.txt which capture explanations of the changes, features and updates for each release. This information is important to also track the evolution of features over time. Of course it would also be wise to review the source, particularly the deployment scripts. When compiling your distribution, it could be good to also take a look at the portable distribution to well understand the composition of components for a successful runtime instance.

(2016-12-14, 22:57)Milan Vančura Wrote: First run - the creation of the first user configuration:

* LPub3D creates new directory tree on its own ($HOME/.local/share/LPub3D Software/LPub3D/) but it forgets to create some files there and complains to me instead: "extras/titleAnnotations.lst", "extras/fadeStepColorParts.lst", "extras/pliSubstituteParts.lst".

* to make it more annoying, it cries later about missing titleAnnotations.lst file before rendering each and every step

This behaviour most likely results from an incomplete runtime state. LPub3D is not runtime ready after compilation. There is additional content required which is positioned by the deployment scripts during installation or pre-positioned, as is the case for portable distributions. If you expect to successfully launch after compilation then it will be necessary to pre-position the dependent content accordingly.

(2016-12-14, 22:57)Milan Vančura Wrote: * Preferences: after typing the ldglite path manually the roller "preferred renderer" does not get any value and "Required settings are missing..." warning pops up after hitting "OK" button. The workaround is to click on "Browse", even I do not need to change the path. Then, everything works.

I'll take a look. This behaviour is unexpected as the error message should not present if the renderer path dialog is not empty - which it is not because you manually typed in the entry.

This is a good question and further details are captured in the readme I mentioned earlier. But to give a brief explanation, for performance and interoperability between LPub3D editor and the 3D viewer - based on LeoCAD, the solution architecture uses Ldraw archive libraries for official and unofficial LDraw content. This approach is vaguely similar to the shadow files of LDCad for example. Particularly when considering the unofficial LDraw library which is supports the loading and exchange of custom and faded part files between the editor and viewer.

The LDraw library path is required as it is used to update the archive libraries (mainly the unofficial archive) with any new parts added to the library. It is also used to generate the part list used to identify parts with static colours and as a possible location of the ldrawini file.

(2016-12-14, 22:57)Milan Vančura Wrote: * LPub3D tries to get some archive of unofficial parts - how can I point it to my "Unofficial" subdirectory of my ldraw tree instead? Same as what I use and/or used with LDCad, LPub4, SR3D Builder...

The loading of unofficial parts into the unofficial archive at startup is an automatic function which does not need or support user intervention. The only requirement is to point LPub3D to your LDraw directory at installation. If your LDraw directory is not detected at startup, you will be prompted by LPub3D as you have discovered. If one would like to add other unofficial file locations, this is possible using the ldrawini framework and/or directly updating entries in Preferences/Other/LDraw Content Search Directories.

(2016-12-14, 22:57)Milan Vančura Wrote: * ctrl-O does not work

Many of the shortcuts do not currently work. I keep forgetting to fix them. I'll fix for the next release. The behaviour root cause is mostly because of conflicts with similar shortcut definitions between the the LPub3D editor and 3D viewer.

(2016-12-14, 22:57)Milan Vančura Wrote: * ctrl-S tries to "save the project" even when nothing is open

This behaviour was corrected sometime after 2.0.6.

(2016-12-14, 22:57)Milan Vančura Wrote: * I do not understand how to "synchronize" the angle of current step and the angle in that 3D window. A different angle is shown there and if I rotate with that 3D view and press "insert rotstep" button, I get completely different view in the rotstep than it is shown in the 3D sidebar.

In 2.0.6 the difference in views represent a fixed offset between the editor and viewer. This behaviour is because the LPub and LeoCAD (3D Viewer) coordinate system are not the same - If I can remember well, the Y axis is inverted in LeoCAD. Moreover, the default camera globe settings were not the same either. Lastly, LPub3D (legacy LPub behaviour) performed rotation on all CSI parts equal to the the default rotation (x=23,y=45,z=0) before rendering, presenting these 'rotated' parts to the viewer then resulted in further rotation offset. You can see details of this behaviour in step.h/cpp and rotate.h/cpp source files

I have improved this behaviour after 2.0.6 but it is still not as I would like it and I continue to look for a better scheme to synchronize the 2 views.

(2016-12-14, 22:57)Milan Vančura Wrote: The program crashes with segmentation fault in several cases, I try to map them and solve what I can.

It would be quite helpful to know a bit more about where/when the application crashes.

Thanks for your reply, Trevor. This casts new light: I found a link to the git tree on sf.net but to that old one (2.0.6) only, I did not understand why. But probably it was caused by the fact I was there anonymously. I'm not at home today but tomorrow, I try to create my own account at sf.net and see what branches I'll get then. This might change a lot

About Linux testing, renderers and so on: that's exactly what I'm working on, with one friend of mine. We created a set of repositories for many of well-known linux distros and we package the ldraw SW there. I want to add LPub3D as well, that's my goal, of course. So you can use packages we already have there. Unfortunately, we did not have time to fix some dependencies issues of ldglite at RedHat systems (Fedora, CentOS). I might try to fix them if you need CentOS. Meanwhile, you can install that on openSUSE, Debian or Ubuntu. I'm not sure now but Arch Linux should work as well.

What I still don't understand is your way of ldraw library management. All other tools (including ones we do not have in our repositories, like LDCad) know to use a directory tree so one of our goals is to configure them automatically, that they all touch the same ldraw library when installed from our packages. It's important to prevent those really-not-funny situations when you can see some parts in your editor but they are silently missing in the generated PDF with instructions, etc. This is something to think more about, in LPub3D case, as I see. But it's too soon for that, I need to create my sf.net account, watch the current code and learn about your "deploy scripts" first.

(2016-12-15, 12:05)Milan Vančura Wrote: Unfortunately, we did not have time to fix some dependencies issues of ldglite at RedHat systems (Fedora, CentOS). I might try to fix them if you need CentOS.

CentOS is more of a server platform and not so common for desktop. I was using it because I used it for work. Anyhow, I've switched to Ubuntu so don't bother to fix any dependencies on my account.

However, ldglite specifically has been updated by Don Heyse (see Don's blog and github) to accommodate LPub3D additional search directories and ldrawini. This is the only version compatible with LPub3D so you should consider updating your ldglite rpm package from 1.2.10 to 1.3.1 with the 2g2x modification.

(2016-12-15, 12:05)Milan Vančura Wrote: What I still don't understand is your way of ldraw library management.

Just consider that LPub3D uses the LDraw archive libraries instead of the unarchived libraries to identify parts and to display parts in the 3D viewer. The archive libraries should be provided for runtime but can also be downloaded on demand.

In addition to what was mentioned in my previous post, LPub3D must still capture the unarchived LDraw library path as it is part of the parameter set sent to the ldglite renderer.

(2016-12-15, 9:34)Trevor Sandy Wrote: You should have read access. Read permissions are enabled for anonymous users by default. If you care to set up and forward your sourceforge user id, I'll be pleased to add you to the repository with read/write access. Or, we can continue to exchange via mail/posts. You can see my email in the help/about dialogue.

Just a quick update, I will have more time during the weekend: I can see both master and x11 branch and it's the same tree I made the clone before - I see you added big commits forwarding the code to 2.0.19 at once. That's good, I can work with more current code now. But it would be even better if you can give me the access to the real development branch where I can see separate commits with features and fixes - this would help me a lot to understand the code.
If it is possible...

(2016-12-09, 9:26)Merlijn Wissink Wrote: ...callout in a callout doesn't look very well :
I don't know what's happening here, but it sure isn't what it's supposed to do. Any ideas?

I didn't know nested callouts were possible in LPub3D or LPub for that matter

I certainly haven't released any functionality of the sort; furthermore, the legacy LPub code suggest this behaviour is explicitly forbidden.

Code:

// This is what's supposed to happen when a callout [begin] meta is encountered.
case CalloutBeginRc:
if (callout) {
parseError("Nested CALLOUT not allowed within the same file",current);
} else {
callout = new Callout(curMeta,view);
callout->setTopOfCallout(current);
}
break;

Did the behaviour you expected exist on any earlier version of the software?

It would be interesting to see an example of the LPub meta pattern you used in the model file to produce nested callouts.

Cheers,

I'd swear I've seen callouts in callouts in the past. But, I couldn't quickly find an example. Now I start to doubt myself
Still, I can 'remember' it so clearly: the red box inside the yellow box; callout in a callout. I'll browse through some more instructions, see if I can find something like that anywhere. Maybe my mind is just plain wrong...

How I produced it: I'm not 100% sure (my memory is not... great ), but I believe I just created a callout from the 'parent' callout. Then I saw that little square and I realized the submodel in the parent also used a callout. I thought I needed to create the child-callout first, so I pressed undo, went to the child-submodel, transformed that into a callout (the child-callout) and then transformed the parent submodel back into a callout (parent callout). Still, just a little square.

Nested callouts are indeed supported when the 'child' callout is in a different mpd-format FILE (meta) or separate ldr-format file [Philo's example].

The LPub3D behaviour you are experiencing is a current limitation of the recently released LDView Single Call Rendering feature.

If you un-check 'Use multiple files single call rendering' (Configuration/Preferences/Rendering Tab/LDView is installed menu group) or change your 'Preferred renderer' to LDGLite, the nested callout will display as expected.

The current behaviour is a result of the single call parse not iterating to the level of the nested callout assembly (CSI) so only the PLI (if displayed) is presented. I will take a look at redesigning this logic.

I haven't used buffer-exchange in quite a while, but I need it again now. But, it looks like LPub3D doesn't handle it correctly (anymore). Or I'm just not using buffer-exchange correctly, that's also a possibility

This is an excerpt from my file (I added some extra step numbers for clarity, they are not in the actual file):

Step 1, everything seems fine. It shows the submodel, the buffered part and the arrow (which for whatever reason is not in the parts list, but that's good obviously )

Step 2, here things get a bit wrong. LPub3D correctly removes the buffered 32062 and the arrow from the assembly view and it correctly shows the new buffered 32062 and arrow. BUT, it hows 2x 32062 in the parts list. That should be 1x.

Step 3, the same as step 2. It correctly removes the buffered parts from the view, but it still lists 1x 32062 again in the parts list...

I have added 2 buffer exchanges so far and both show this behavior.
So, am I doing something wrong or is LPub3D doing something wrong?

(2016-12-27, 10:05)Merlijn Wissink Wrote: I haven't used buffer-exchange in quite a while, but I need it again now. But, it looks like LPub3D doesn't handle it correctly (anymore). Or I'm just not using buffer-exchange correctly, that's also a possibility

This is an excerpt from my file (I added some extra step numbers for clarity, they are not in the actual file):

Step 1, everything seems fine. It shows the submodel, the buffered part and the arrow (which for whatever reason is not in the parts list, but that's good obviously )

Step 2, here things get a bit wrong. LPub3D correctly removes the buffered 32062 and the arrow from the assembly view and it correctly shows the new buffered 32062 and arrow. BUT, it hows 2x 32062 in the parts list. That should be 1x.

Step 3, the same as step 2. It correctly removes the buffered parts from the view, but it still lists 1x 32062 again in the parts list...

I have added 2 buffer exchanges so far and both show this behavior.
So, am I doing something wrong or is LPub3D doing something wrong?

The post presents a detail use case with supporting LPub3D and LPub assets comparing and explaining how the BUFEXCHG meta should be used. I believe an anomaly in the way LPub managed its cache files, and the difference in the way MLCAD treats the meta, have led to incorrect expectations about the way the meta can be used with LPub3D.

The post presents a detail use case with supporting LPub3D and LPub assets comparing and explaining how the BUFEXCHG meta should be used. I believe an anomaly in the way LPub managed its cache files, and the difference in the way MLCAD treats the meta, have led to incorrect expectations about the way the meta can be used with LPub3D.

Cheers,

Well, as in the post you linked, I expect 'V1 correct behavior' but I'm seeing 'V1 incorrect behavior'. I'm 1000% sure that an old version of LPub had the 'correct' behavior, as shown by Johann.

But of course it depends on what you think is correct. Now that I think of it, I think it's better to call the 'incorrect' version on your link the 'correct' version (because technically, it's doing exactly what the file says) and to call the 'correct' version the 'desired' version. Because, 99% of the time you use buffer exchange, you want a floating part with arrows in step 1 and the part in its final position in step 2 without adding it to the PLI again.

As the post described, a way of doing it currently is by adding ignore commands to all final-position parts. But, in a large model, that'll start to clutter up a lot of things and it's very inconvenient. Maybe, just maybe, we need to introduce a new command? After all, buffer-exchange is an (ancient) MLCad-command and LPub just added support for that. There's no reason LPub3D can't introduce its own command (there are so many already after all).

I'm just thinking out loud here, but maybe something like this (based on MLCad's version, it doesn't have to be completely different):

Code:

[other parts in the step]
0 !LPUB BUFFER A STORE BEGIN
[parts and arrows to store here]
0 !LPUB BUFFER A STORE END
[other parts in the step]

0 STEP

[other parts in the step]
0 !LPUB BUFFER A RETRIEVE BEGIN
[final position parts]
0 !LPUB BUFFER A RETRIEVE END
[other parts in the step]

It's not too different from the MLCad version, but it does solve a lot of headaches. Because it has a clear begin and end for both the store and retrieve commands, it would be fairly easy for LPub3D to automatically make correct assemblies and PLIs. And, it also makes adding it way less of a headache, current buffer exchange is position-dependent, which is incredibly annoying if you forget to move a line up or down
Now, of course, you could also take it a step further and make a more complicated buffer exchange with more features. Cross-submodel buffer store/retrieve for example (in other words, e.g. buffer A is not only known in the submodel it's in, but is known model-wide), but I have no idea if that would be easy to use at all.

On the post I linked, I hadn't really looked at Johann's update so If his scenario is different from Artius' then I will certainly update LPub3D if it is determined to be in regression. On the other hand, I clearly demonstrated that Artius' expectation was actually not the way either LPub3D or even LPub actually behaved. This position is demonstrated in the post I shared.

So. I am open to evolving the BUFEXCHG behaviour (while keeping backward compatibility of course) to make it more efficient because some users seem to be confused by the current behaviour (I get lots of request on the good pattern to implement). Moreover, the feature is quite valuable to producing hi-fidelity instructions.

Im wrapping up my x11 ports (Linux and OSX) so I should be in a position to take a look at putting this on the stack after that. Do not hesitate if you have any additional ideas on how we could improve this feature.

On the post I linked, I hadn't really looked at Johann's update so If his scenario is different from Artius' then I will certainly update LPub3D if it is determined to be in regression. On the other hand, I clearly demonstrated that Artius' expectation was actually not the way either LPub3D or even LPub actually behaved. This position is demonstrated in the post I shared.

So. I am open to evolving the BUFEXCHG behaviour (while keeping backward compatibility of course) to make it more efficient because some users seem to be confused by the current behaviour (I get lots of request on the good pattern to implement). Moreover, the feature is quite valuable to producing hi-fidelity instructions.

Im wrapping up my x11 ports (Linux and OSX) so I should be in a position to take a look at putting this on the stack after that. Do not hesitate if you have any additional ideas on how we could improve this feature.

Cheers,

Great! I'll see if I can think about other things that would be nice to have.
One thing popped up yesterday already: with the current buffer exchange, if I store a buffer in the last step of a submodel, there's no way to retrieve that buffer without adding an (unnecessary) extra step. That's another reason a global buffer (vs a submodel-level buffer) would be nice.

Another example: a lot of Technic models use that pin-with-bush part. Often times, it's attached on a submodel not fully pressed. Then you place the submodel on the main model and you fully press the pins-with-bushes. With the current buffer, that's also not possible*.

I hope that all makes a bit sense. Writing clear texts is by far not my greatest skill

*unless you make a little hack and you create 2 submodels, one with fully pressed pins and one with semi-pressed pins. Then buffer the whole submodel with semi-pressed pins and then retrieve that one and swap it with the one with fully pressed pins.

It would be nice if the callout command would also work on parts. Sometimes, a callout is handy to point out a difficult to see part. Currently, one would need to create a submodel with a single part to create a callout for that part. It would be nice if the current callout command would also work on parts.

when I change the orientation of a call-out in a submodel, it actually places/changes the command in the main model instead of in the submodel. Which means that when I have multiple call-outs in a single submodel, things keep getting changed. Lemme (try to) explain:

Let's say I have a example.mpd with a submodel subA which contains 2 other submodels subB and subC:
example.mpd
subA.ldr
subB.ldr
subC.ldr

subB and and subC are both callouts. However, subB needs a horizontal orientation and subC needs a vertical orientation.
So, while formatting the instructions in LPub3D, I come across subB and I change it to horizontal. LPub3D however, places the '!LPUB CALLOUT ALLOC HORIZONTAL' in example.mpd instead of in subA. It still works as desired though, because LPub3D reads the file from top to bottom. But, then I come across subC. It needs to be vertical, so I change it to vertical. But, LPub3D just changes the command in example.mpd from horizontal to vertical, which means that subB is now also vertical again. You'd go back to subB, set it to horizontal again, but that changes subC again. It's an endless circle.

If LPub3D would just put the '!LPUB CALLOUT ALLOC [orientation]' in the subfile where the callout is, it would solve all problems. I'm currently adding these commands manually and it works like a charm.
I haven't investigated it very much though, so it might be a little different than how I've explained it.

I'm at a good point with the AIOI (glad I didn't have to add the vc2015) just extracting content from the zip. However the dialog for "Change log for 2.0.19" says:

Code:

Failed to open C:/Users/XXXX/Desktop/README.txt
No such file or directory

a copy of README.txt is present in the docs folder (I stripped the one in LPub3D_x32-2.0.19.877.2_20161208 folder in the zip as it would end up in the C:\Program Files (x86)\LDraw folder). I also checked the registry for a path but couldn't find any. The only source I found was:

Code:

SetOutPath "$INSTDIR"
File "..\docs\README.txt"

in your installer script. I therefore wonder why you would store a change log file on the Desktop and where I do change the search path?

(2017-01-09, 15:46)Willy Tschager Wrote: in your installer script. I therefore wonder why you would store a change log file on the Desktop and where I do change the search path?

Willy - Sorry for the delayed response

LPub3D does not store its README on the desktop. The README is stored at install_root and install_root/docs

The 'Change log' dialogue on the Preferences form (and also on the Help->About LPub3D form) looks for the README at the current working directory (cwd.absolutePath()) - this defaults to where the LPub3d.exe is located.

I'm not sure how you got the response you did but I imagine you would have to run the LPub3D portable distribution from your desktop to get that response.

Code:

SetOutPath "$INSTDIR"
File "..\docs\README.txt"

This code is meaningless in your context. The first line instructs NSIS to set the working directory to where LPub3D will be installed. The second line defines where to find the README file for packaging in the NSIS installer.

Using the POV-Ray rendering in version 2.0.19 is _very_ slow generating the image for a Panel 1 x 2 x 2 - Hollow Studs — BrickLink part 4864b in color 47 trans clear. It's OK; I have time; it's possibly a clue that my computer is maxed out somehow. But eventually LPub3D crashes.

I'm building a chimney for a Great Ball Contraption ball pump and LPub3D can successfully generate a POV image with up to eight of those panels. When adding more of them, LPub3D crashed and asked me to forward this dump file to the developers.

I'm going to experiment with using solid studs part 4864a and a more opaque color.

Hello Walt. I'll take a look. However, note that LPub3D does not do any rendering, it is responsible only to send L3P the appropriate flags and part list to be rendered. L3P produces the .pov file which LPub3D then forwards to POV-Ray and waits for the POV-ray process result before attempting to consume the rendered image - get the size details, convert to pixmap and place in the document.

If you are experiencing excessive delay, the source is likely POV-Ray. However, it is a good idea to confirm the .pov file is well formed. The command line used to generate the pov image is captured in the .pov file and in the POV-Ray console during execution. You can use it to confirm the source of your delay.

Ok, so I found another bug (kinda I think). And it would be great if you could quickly fix this one

I want the placement of the step-number the same as in official instructions: under the parts list at the left side. So, I right-clicked the step number and positioned it at the bottom-left of the parts-list. But, then the part number went into the parts list. That's already wrong. Doesn't matter which position I chose relative to the parts-list, the part number always went to the top-left corner of the PLI.

I thought I could maybe fix it by changing the PLI position. I changed the PLI position from relative to the part-number to relative to the page (top-left corner). Then I changed the position of the step number again. Again, bottom-left relative to the PLI. But, now the part number constantly goes to the center of the page (whichever position relative to the PLI I choose)

Today I fired up LPub3D and it said there was a new version available (2.0.20 I believe). There was a button to view 'Whats new', but it had horrible formatting and was super tiny. So, I just pressed update and went online to find a better changelog. But I can't find any (in fact, the sourceforge page doesn't even show 2.0.20). Does anyone know the changelog?

(2017-02-03, 14:14)Merlijn Wissink Wrote: Today I fired up LPub3D and it said there was a new version available (2.0.20 I believe).
...
But I can't find any (in fact, the sourceforge page doesn't even show 2.0.20).

This is because 2.0.20 was not released at that time

You received the new update prompt because I was testing the update capability for the new Linux/Mac distributions. In fact, the download could have actually been 2.0.19 even if the file name said otherwise.

It would be a good idea to update your installation with the LPub3D 2.0.20 I released today - some hours ago.

Features and enhancements
------------
Fix: Introducing LPub3D ports for Linux (Debian, Red Hat and Arch based distros) and Mac (OSX). [0853680]
* LPub3D is now available across Windows, Linux and Mac platforms. The LPub3D package can be accessed via direct download from sourceforge.net and is available in .dmg (OSX), .rpm (Red Hat)
.deb (Debian) and .pkg.tar.xz (Arch) formats. Additionally, LPub3D can be built directly from source with the provided .spec, Debian configuration files or PKGBUILD build
configuration files. LPub3D source for building Linux distros is available at https://github.com/trevorsandy/lpub3d; LPub3D source also remains available at http://sourceforge.net/p/lpub3d/code/.
Fix: When the preferred renderer is manually typed into the preference dialogue, it is not validated upon exit of the preferences dialogue. [44548f4]
* This behaviour has been corrected. Manually entered preferred render path is validated when the preference dialogue is closed.
Fix: Automatically load LDraw archive libraries on initial application launch. [ff06bc9]
* To further improve the user experience at initial application launch. When LPub3D is loaded for the first time, it there are no archive libraries in at the user's application data path. LPub3D will automatically install the libraries packaged in the distribution.
Fix: Update QuaZip library to v0.7.2
* Improve robustness.
Fix: Enable and correct menu shortcuts. [48ca363]
* LPub3D menu item keyboard shortcuts have been repositioned to allow both Editor, and 3DViewer's short cuts to reside on the main menu tool-bar. This redesign allows for more seamless integration on OSX and some Linux distros - e.g. Debian.
Additionally, all available LPub3D menu item short cuts are now enabled. Here are the new mappings:

(2017-02-12, 11:18)Jaco van der Molen Wrote: Perhaps something is wrong on my machine but do you have any idea what can be done?

Hi Jaco,

Interesting, the behaviour you are experiencing should not be so under a normal scenario.

Basically, during launch LPub3D is looking for it's AppData store (at the location indicated in the response message) but somehow it is not there. The strange part is LPub3D will normally create the AppData store and populate it with the required content during application launch if it is not detected. So it looks like your installation is not able to create and populate the AppData content during application launch.

The AppData content is archived during the application installation at '/Applications/LPub3D.app/Contents/Resources'.

You can manually copy and paste this content from the archive location to the AppData location. Be sure to put the archive libraries under '/Users/jaco/Library/Application Support/LPub3D Software/LPub3D/libraries'.

I didn't add any logic to hide the splash screen during AppData population as this is not supposed to fail. However, I'll revisit this since that premise is obviously false.

About trying to find LDraw directory, the behaviour is to automatically look at /Users/jaco/Library/LDraw, then /Library/LDraw, then prompt the user to enter a valid LDraw path. If the entered/selected path is not valid, then you will receive a message to exit or continue. Continuing will restart the logic to find a valid LDraw directory as described above. When prompted, the splash screen should be hidden from view.

I tested this routine multiple time so it's surprising to see it's failing. I'll check once again as I'm updating the packaging process for open build service implementation.

Let me know if you environment is unusual in any way or if you performed/encountered any non-standard behaviour during installation. This way I can treat any exceptions accordingly.

I manually create the folders and put the files in. But apparently not in the right folder.
Since my Mac is localized as a Dutch machnine, I thought the "/Users/jaco/Library/" part would translate to "Gebruikers/jaco/Bibliotheek".

Somehow, I still was able to find /Users/jaco/Library/Application Support/LPub3D Software/LPub3D/libraries

There were no files titleAnnotations.lst and pliSubstituteParts.lst in the LPub3D package, so I copied them from my Windows installation.
I also missed the freeformAnnotations.lst.

So, still I am unsure how I did it, but it seems LPub3D can fine the .lst files now.

Now for the settings: they are not kept.

Rendering a model works fine now. But every time I have to look for LDView...

(2017-02-13, 16:53)Jaco van der Molen Wrote: There were no files titleAnnotations.lst and pliSubstituteParts.lst in the LPub3D package, so I copied them from my Windows installation.
I also missed the freeformAnnotations.lst.

So it looks like the parameter files are missing - this explains why they were not written. I'll take a look at the build to see if there was problem I missed

(2017-02-13, 16:53)Jaco van der Molen Wrote: Now for the settings: they are not kept.

Rendering a model works fine now. But every time I have to look for LDView...

This one is a bit strange. Perhaps these anomalies are linked to mis-matched localization (Dutch/English) ? Are the application parameters written to

Code:

~/Library/Preferences/

? I don't remember exactly the plist names but they should all include lpub3d...

For your installation, did the

Code:

/Applications/LPub3D.app/Contents/Resources

folder contain any files at all ? It's quite strange because if those parameter files were not packed, the packaging process should fail - it did not

I'm not sure what happened with my packaging solution, but it apparently only packed half of the required files.

As you already know, the work-around here is to manually copy the missing files into LPub3D.app/Contents/Resources or
~/Library/Application Support/LPub3D Software/LPub3D/extras.

Regarding the splash screen. for future reference. I you are blocked by it, just click on any other open window/document on the screen and the OS will automatically hide the splash as the other component takes focus. It will come back when you click on the 'covered dialogue' but the dialogue will still take your action to move/close whatever.

I have an LDraw file which starts at portrait, then goes to landscape and then to portrait again.
It looks perfectly fine in the LPub3D editor. But, when I export, it switches to landscape 1 page to early. It does switch back to portrait at the right page though.

It's kinda confusing, because the editor shows one thing, while the export does the other thing.

I have the feeling this problem is kinda related to the one above. I have a 'raw' LDraw file without any LPub commands. I open it in LPub3D and set the page to A4 landscape. Everything looks fine in the editor, but the exported pdf is in A4 portrait

Not the whole pdf though, the very last page is in landscape. The LDraw is still a WIP. It has a bunch of submodels that are all thrown together in the main model at the last page (so the main model has just 1 'step'). The instructions start at a submodel. Maybe that has something to do with the problem?

Also, the pdf is in portrait mode, but you can clearly see that the thing it was trying to export was landscape and has been cut off to portrait again.

The weirdest thing to me still, is how the editor can show the page correctly in landscape, while the pdf export is in portrait. How does that happen?

I'm still waiting for the 'continuous step-number'. So step numbers don't reset for every submodel but keep on counting (except for call-outs).

I believe this has been asked before, but if this feature can be released within a few weeks that would be a godsend. I could use it very well for a project I'm working on.

It seems like Trevor hasn't been online here anymore for quite some time. I figured I could take a look at the source code myself and I actually got a (very) vague idea of where to (possibly) make such a change. But I've almost never used c++ and I don't know all the ins and outs of compiling and building the actual application. It also needs the qt stuff and all of that and I have no idea how to use that either.