Some more findings in LPub3D

[Jaco van der Molen]

Hi Trevor,

Making instructions I have found some "bugs" in LPub3D.

Model Description does not respond to placing it somewhere relative to the page
For example:
0 !LPUB PAGE MODEL_DESCRIPTION PLACEMENT LOCAL TOP PAGE INSIDE
0 !LPUB PAGE MODEL_DESCRIPTION PLACEMENT LOCAL TOP_RIGHT PAGE INSIDE
do not work and keeps placing the description top left

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.
For example the model I am working on now has 768 parts and LPub3D gives 753.

Assembly margins in a callout only seem to affect the top (or bottom) margin
Horizontal margins have no effect. Setting a margin in a call out separator gives odd results too.

If I find more I'll let you know.

[Trevor Sandy]

Model Description does not respond to placing it somewhere relative to the page
For example:
0 !LPUB PAGE MODEL_DESCRIPTION PLACEMENT LOCAL TOP PAGE INSIDE
0 !LPUB PAGE MODEL_DESCRIPTION PLACEMENT LOCAL TOP_RIGHT PAGE INSIDE
do not work and keeps placing the description top left

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.
For example the model I am working on now has 768 parts and LPub3D gives 753.

Assembly margins in a callout only seem to affect the top (or bottom) margin
Horizontal margins have no effect. Setting a margin in a call out separator gives odd results too.

Jaco,

Thanks for sending these findings. Indeed, items 1 and 2 are known areas of weakness. Actually, I have to rewrite the page attributes functionality because (among other limitations) they are placed relative to each other which can give strange behaviors. 

On the second item, the logic to properly identify used parts is really tricky. At some point I have to design a more consistent framework. I'll take a look.

I was not aware of the last item. If you can model an example that would be excellent.

... on my side, good news! I finished the patch for managing mixed page size and orientation during printing. It was a bit of a challenge but it was fun. Basically, LPub 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 seems unhappy when you try to switch page size while the printer is active. Switching to the pdfWriter engine removes the limitation on both size and orientation while the 'printer' is active.

Some images...

pdf document:
   

png images:
   

Cheers,

[Jaco van der Molen]

Thanks for sending these findings. Indeed, items 1 and 2 are known areas of weakness. Actually, I have to rewrite the page attributes functionality because (among other limitations) they are placed relative to each other which can give strange behaviors. 

On the second item, the logic to properly identify used parts is really tricky. At some point I have to design a more consistent framework. I'll take a look.

I was not aware of the last item. If you can model an example that would be excellent.

OK, I'll make an example.

... on my side, good news! I finished the patch for managing mixed page size and orientation during printing. It was a bit of a challenge but it was fun. Basically, LPub 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 seems unhappy when you try to switch page size while the printer is active. Switching to the pdfWriter engine removes the limitation on both size and orientation while the 'printer' is active.

Great! Is that in 2.0.10?

[Trevor Sandy]

Great! Is that in 2.0.10?

No - 2.0.10 is already released. It will be in 2.0.11.

I also reworked the page attributes behaviour. As you know most are by default 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:

Code:

  * Front Cover Default Attribute Placements
  *************************************
  *   Logo                            *  (Top Left of Page) [Independent]
  *                                   *
  *   ModelName                       *  (Top of Title) [Dependent]
  *   Title                           *  (Left Center of Page) [Anchor]
  *   Author                          *  (Bottom of Title) [Dependent]
  *   Pieces                          *  (Bottom of Author) [Dependent]
  *   Model Description               *  (Bottom of Pieces) [Dependent]
  *   Publisher Description           *  (Bottom of Model Description) [Dependent]
  *                                   *
  *************************************

  * Header/Footer Default Attribute Placements
  * ***********************************
  * URL (Top Left of Page)            Email (Top Right of Page)
  * ***********************************
  * *                                 *
  * *                                 *
  * *                                 *
  * *                                 *
  * ***********************************
  * Copyright (Bottom Left of Page)   Author (Bottom Right of Page)
  * ***********************************

  * Back Cover Default Attribute Placements
  * **********************************
  *               Logo               *  (Top of Page) [Independent]
  *  Title                           *  (Center of Page) [Anchor]
  *  Author                          *  (Bottom of Title) [Dependent]
  *  Copyright                       *  (Bottom of Author) [Dependent]
  *  URL                             *  (Bottom of Copyright) [Dependent]
  *  Email                           *  (Bottom of URL) [Dependent]
  *  LEGO Disclaimer                 *  (Bottom of Email) [Dependent]
  *  LPub3D Plug                     *  (Bottom of LEGO Disclaimer)
  *  LPub3D Plug Image               *  (Bottom of Page) [Independent]
  *                                  *
  ************************************

Cheers,

[Jaco van der Molen]

Great stuff there!
Don't mean to rush you, but when is 2.0.11 comming? ;-)

[Trevor Sandy]

Don't mean to rush you, but when is 2.0.11 comming? ;-)

Likely this weekend - if I don't agree to complete/include the number of pieces fix.

On the number of pieces fix topic; I imagine I'll have to write some sort of logic module to account for the myriad of alternatives/exceptions possible when counting parts. Some example alternatives are what is the user defining as a part? LDraw parts, LEGO parts, custom assembly (e.g. LDCad template), submodel treated as part by LPub3D etc...

The challenge here is 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. I 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.

If you don't mind, can you PM me the model file you referenced in your earlier post indicating an accurate part count ? I will use it to investigate/validate my count logic. It would also be good to know what you expect to be counted as a 'part' in the said model file ?

Cheers,

[Jaco van der Molen]

PM sent.